name: semgrep-rule-variant-creator description: 创建现有Semgrep规则的语言变体。用于将Semgrep规则移植到指定的目标语言。以现有规则和目标语言作为输入，为每种语言生成独立的规则+测试目录。 allowed-tools:
- Bash
- Read
- Write
- Edit
- Glob
- Grep
- WebFetch
Semgrep规则变体创建器
将现有Semgrep规则移植到新的目标语言，进行适当的适用性分析和测试驱动验证。
何时使用
理想场景：
- 将现有Semgrep规则移植到一个或多个目标语言
- 创建通用漏洞模式的语言特定变体
- 在多语言代码库中扩展规则覆盖范围
- 在具有等效结构的语言之间翻译规则
何时不使用
不要使用此技能用于：
- 从头创建新的Semgrep规则（使用
semgrep-rule-creator代替） - 对代码运行现有规则
- 漏洞模式在根本上不适用于的语言
- 同一语言内的次要语法变体
输入规范
此技能需要：
- 现有Semgrep规则 - YAML文件路径或YAML规则内容
- 目标语言 - 一个或多个要移植到的语言（例如，“Golang和Java”）
输出规范
对于每个适用的目标语言，产生：
<原始规则ID>-<语言>/
├── <原始规则ID>-<语言>.yaml # 移植的Semgrep规则
└── <原始规则ID>-<语言>.<ext> # 带注释的测试文件
移植sql-injection到Go和Java的示例输出：
sql-injection-golang/
├── sql-injection-golang.yaml
└── sql-injection-golang.go
sql-injection-java/
├── sql-injection-java.yaml
└── sql-injection-java.java
拒绝的合理化
当移植Semgrep规则时，拒绝这些常见捷径：
| 合理化 | 为何失败 | 正确方法 |
|---|---|---|
| “模式结构相同” | 不同语言间的AST不同 | 始终为目标语言转储AST |
| “相同漏洞，相同检测” | 语言间的数据流不同 | 分析目标语言惯用语 |
| “规则不需要测试，因为原始规则有效” | 语言边缘情况不同 | 为目标语言编写新测试案例 |
| “跳过适用性 - 它显然适用” | 有些模式是语言特定的 | 首先完成适用性分析 |
| “我将创建所有变体然后测试” | 错误复合，难以调试 | 每种语言完成完整周期 |
| “库等效足够接近” | 表面相似隐藏差异 | 验证API语义匹配 |
| “只是1:1翻译语法” | 语言有不同的惯用语 | 研究目标语言模式 |
严格级别
此工作流程是严格的 - 不要跳过步骤：
- 适用性分析是强制性的：不要假设模式翻译
- 每种语言是独立的：在移动到下一种语言之前完成完整周期
- 每种变体的测试优先：从不写没有测试案例的规则
- 需要100%测试通过：“大多数测试通过”是不可接受的
概述
此技能指导创建现有Semgrep规则的语言特定变体。每个目标语言通过独立的4阶段周期：
FOR EACH target language:
Phase 1: 适用性分析 → 裁决
Phase 2: 测试创建（测试优先）
Phase 3: 规则创建
Phase 4: 验证
(在移动到下一种语言之前完成完整周期)
基础知识
semgrep-rule-creator技能是Semgrep规则创建基础的权威参考。 虽然此技能专注于将现有规则移植到新语言，但编写质量规则的核心原则相同。
参考semgrep-rule-creator以获取指导：
- 何时使用污点模式与模式匹配 - 为漏洞类型选择正确方法
- 测试优先方法论 - 为何测试先于规则以及如何编写有效测试案例
- 要避免的反模式 - 常见错误，如过于宽泛或过于具体的模式
- 迭代直到测试通过 - 验证循环和调试技术
- 规则优化 - 在测试通过后移除冗余模式
当移植规则时，你在新的语言上下文中应用这些相同原则。如果不确定规则结构或方法，请先参考semgrep-rule-creator。
四阶段工作流程
阶段1：适用性分析
在移植之前，确定模式是否适用于目标语言。
分析标准：
- 目标语言中是否存在漏洞类？
- 是否存在等效构造（函数、模式、库）？
- 语义是否足够相似以进行有意义的检测？
裁决选项：
APPLICABLE→ 进行变体创建APPLICABLE_WITH_ADAPTATION→ 进行但需要显著更改NOT_APPLICABLE→ 跳过此语言，记录原因
参见applicability-analysis.md以获取详细指导。
阶段2：测试创建（测试优先）
始终先写测试再写规则。
使用目标语言惯用语创建测试文件：
- 至少2个脆弱案例（
ruleid:） - 至少2个安全案例（
ok:） - 包括语言特定的边缘案例
// ruleid: sql-injection-golang
db.Query("SELECT * FROM users WHERE id = " + userInput)
// ok: sql-injection-golang
db.Query("SELECT * FROM users WHERE id = ?", userInput)
阶段3：规则创建
- 分析AST：
semgrep --dump-ast -l <lang> test-file - 翻译模式为目标语言语法
- 更新元数据：语言键、消息、规则ID
- 适应惯用语：处理语言特定构造
参见language-syntax-guide.md以获取翻译指导。
阶段4：验证
# 验证YAML
semgrep --validate --config rule.yaml
# 运行测试
semgrep --test --config rule.yaml test-file
检查点：输出必须显示All tests passed。
对于污点规则调试：
semgrep --dataflow-traces -f rule.yaml test-file
参见workflow.md以获取详细工作流程和故障排除。
快速参考
| 任务 | 命令 |
|---|---|
| 运行测试 | semgrep --test --config rule.yaml test-file |
| 验证YAML | semgrep --validate --config rule.yaml |
| 转储AST | semgrep --dump-ast -l <lang> <file> |
| 调试污点流 | semgrep --dataflow-traces -f rule.yaml file |
与规则创建的关键差异
| 方面 | semgrep-rule-creator | 此技能 |
|---|---|---|
| 输入 | 错误模式描述 | 现有规则 + 目标语言 |
| 输出 | 单规则+测试 | 多规则+测试目录 |
| 工作流程 | 单创建周期 | 每种语言独立周期 |
| 阶段1 | 问题分析 | 每种语言的适用性分析 |
| 库研究 | 总是相关 | 可选（当原始使用库时） |
文档
必需：在移植规则之前，阅读相关Semgrep文档：
- 规则语法 - YAML结构和操作符
- 模式语法 - 模式匹配和元变量
- 模式示例 - 每种语言模式参考
- 测试规则 - 测试注释
- Trail of Bits测试手册 - 高级模式
下一步
- 对于适用性分析指导，参见applicability-analysis.md
- 对于语言翻译指导，参见language-syntax-guide.md
- 对于详细工作流程和示例，参见workflow.md