opengrep-rule-generator
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseOpengrep Rule Generator
Opengrep规则生成器
Overview
概述
Generate valid opengrep/semgrep YAML rules through collaborative dialogue. Supports two workflows: guided (interactive Q&A to discover what to detect) and vulnerability-driven (given CVEs, OWASP categories, or vulnerability descriptions, generate rules automatically).
通过协作对话生成有效的opengrep/semgrep YAML规则。支持两种工作流:引导式(通过交互式问答确定检测目标)和漏洞驱动式(根据CVE、OWASP分类或漏洞描述自动生成规则)。
When to Use
使用场景
- User says "create a rule", "write a rule", "generate a rule", "detect [vulnerability]"
- User provides a CVE, CWE, or OWASP reference and wants detection rules
- User shares code snippets and asks "how do I catch this pattern?"
- User wants to scan a codebase for a class of vulnerabilities
- User asks to audit code for security issues and wants reusable rules
- 用户提及“创建规则”“编写规则”“生成规则”“检测[漏洞]”
- 用户提供CVE、CWE或OWASP参考并需要检测规则
- 用户分享代码片段并询问“如何捕获这个模式?”
- 用户需要针对某类漏洞扫描代码库
- 用户要求审计代码安全问题并需要可复用规则
Process Flow
流程示意图
dot
digraph rule_gen {
"User request" [shape=doublecircle];
"Has specific vulnerability?" [shape=diamond];
"Guided Discovery" [shape=box];
"Vulnerability-Driven" [shape=box];
"Gather context" [shape=box];
"Choose rule mode" [shape=diamond];
"Generate Search rule" [shape=box];
"Generate Taint rule" [shape=box];
"Present rule for review" [shape=box];
"User approves?" [shape=diamond];
"Write rule file" [shape=box];
"Generate test file" [shape=box];
"Validate with opengrep" [shape=doublecircle];
"User request" -> "Has specific vulnerability?";
"Has specific vulnerability?" -> "Vulnerability-Driven" [label="yes"];
"Has specific vulnerability?" -> "Guided Discovery" [label="no"];
"Guided Discovery" -> "Gather context";
"Vulnerability-Driven" -> "Gather context";
"Gather context" -> "Choose rule mode";
"Choose rule mode" -> "Generate Search rule" [label="pattern match"];
"Choose rule mode" -> "Generate Taint rule" [label="data flow"];
"Generate Search rule" -> "Present rule for review";
"Generate Taint rule" -> "Present rule for review";
"Present rule for review" -> "User approves?";
"User approves?" -> "Present rule for review" [label="revise"];
"User approves?" -> "Write rule file" [label="yes"];
"Write rule file" -> "Generate test file";
"Generate test file" -> "Validate with opengrep";
}dot
digraph rule_gen {
"User request" [shape=doublecircle];
"Has specific vulnerability?" [shape=diamond];
"Guided Discovery" [shape=box];
"Vulnerability-Driven" [shape=box];
"Gather context" [shape=box];
"Choose rule mode" [shape=diamond];
"Generate Search rule" [shape=box];
"Generate Taint rule" [shape=box];
"Present rule for review" [shape=box];
"User approves?" [shape=diamond];
"Write rule file" [shape=box];
"Generate test file" [shape=box];
"Validate with opengrep" [shape=doublecircle];
"User request" -> "Has specific vulnerability?";
"Has specific vulnerability?" -> "Vulnerability-Driven" [label="yes"];
"Has specific vulnerability?" -> "Guided Discovery" [label="no"];
"Guided Discovery" -> "Gather context";
"Vulnerability-Driven" -> "Gather context";
"Gather context" -> "Choose rule mode";
"Choose rule mode" -> "Generate Search rule" [label="pattern match"];
"Choose rule mode" -> "Generate Taint rule" [label="data flow"];
"Generate Search rule" -> "Present rule for review";
"Generate Taint rule" -> "Present rule for review";
"Present rule for review" -> "User approves?";
"User approves?" -> "Present rule for review" [label="revise"];
"User approves?" -> "Write rule file" [label="yes"];
"Write rule file" -> "Generate test file";
"Generate test file" -> "Validate with opengrep";
}Reference Documentation
参考文档
Before generating any rule, load context from these project docs:
| Doc | Path | Load When |
|---|---|---|
| Rule syntax & templates | | Always — contains all operators, templates, language IDs |
| Rule index | | When checking for existing similar rules |
| Engine internals | | When choosing between search vs taint mode |
Also search existing rules for similar patterns:
- — community rules
semgrep-rules/semgrep-rules/<language>/ - — Trail of Bits rules
semgrep-rules-trailbits/<language>/
生成任何规则前,请从以下项目文档加载上下文:
| 文档 | 路径 | 加载时机 |
|---|---|---|
| 规则语法与模板 | | 始终加载 — 包含所有运算符、模板、语言ID |
| 规则索引 | | 检查是否存在类似规则时加载 |
| 引擎内部机制 | | 选择搜索模式与污点模式时加载 |
同时搜索现有规则以查找类似模式:
- — 社区规则
semgrep-rules/semgrep-rules/<language>/ - — Trail of Bits规则
semgrep-rules-trailbits/<language>/
Workflow 1: Guided Discovery
工作流1:引导式发现
Ask these questions one at a time to scope the rule:
依次提出以下问题以明确规则范围:
Step 1 — What are we detecting?
步骤1 — 检测目标是什么?
What vulnerability, bug pattern, or coding anti-pattern do you want to detect?
Examples:
- "SQL injection in our Flask app"
- "Hardcoded secrets in config files"
- "Missing null checks after API calls"
- "Insecure deserialization"
- "Race conditions in Go goroutines"你想要检测哪种漏洞、错误模式或编码反模式?
示例:
- "Flask应用中的SQL注入"
- "配置文件中的硬编码密钥"
- "API调用后缺少空值检查"
- "不安全的反序列化"
- "Go协程中的竞态条件"Step 2 — What language and frameworks?
步骤2 — 使用的语言和框架?
What programming language(s) and frameworks are involved?
I support 30+ languages including: python, javascript, typescript, java, go,
ruby, php, csharp, c, rust, scala, kotlin, swift, terraform/hcl, yaml,
dockerfile, solidity, and more. I also support 'generic' for config files
and 'regex' for raw text matching.涉及哪些编程语言和框架?
我支持30+种语言,包括:python、javascript、typescript、java、go、
ruby、php、csharp、c、rust、scala、kotlin、swift、terraform/hcl、yaml、
dockerfile、solidity等。我还支持针对配置文件的'generic'模式和针对原始文本匹配的'regex'模式。Step 3 — Show me the vulnerable code
步骤3 — 展示漏洞代码示例
Can you show me an example of the VULNERABLE code you want to catch?
And if possible, also show the SAFE version (the fix)?
This helps me write precise patterns with fewer false positives.能否展示你想要捕获的**漏洞代码**示例?
如果可能,同时展示**安全版本**(修复后的代码)?
这有助于我编写精确的模式,减少误报。Step 4 — Where does user input enter? (if applicable)
步骤4 — 用户输入的入口在哪里?(如适用)
Does this vulnerability involve untrusted user input flowing into a dangerous function?
If yes, I'll use TAINT MODE (tracks data flow from sources to sinks).
If no, I'll use SEARCH MODE (structural pattern matching).
For taint mode, I need to know:
- Sources: Where does untrusted data come from? (HTTP requests, file reads, env vars, etc.)
- Sinks: Where is it dangerous? (SQL queries, system commands, file writes, etc.)
- Sanitizers: What makes the data safe? (escaping, validation, type casting, etc.)该漏洞是否涉及不受信任的用户输入流向危险函数?
如果是,我将使用**TAINT模式**(跟踪数据从源头到 sink 的流动)。
如果否,我将使用**SEARCH模式**(结构化模式匹配)。
对于污点模式,我需要了解:
- 源头:不受信任的数据来自何处?(HTTP请求、文件读取、环境变量等)
- Sink:数据在哪里变得危险?(SQL查询、系统命令、文件写入等)
- 净化器:什么操作能让数据变得安全?(转义、验证、类型转换等)Step 5 — Severity and scope
步骤5 — 严重程度与范围
How severe is this issue?
- CRITICAL/ERROR: Exploitable vulnerability, must fix
- WARNING/MEDIUM: Likely vulnerability, should fix
- INFO/LOW: Code smell or audit flag
Should the rule apply to all files, or specific paths only?该问题的严重程度如何?
- CRITICAL/ERROR:可被利用的漏洞,必须修复
- WARNING/MEDIUM:可能存在的漏洞,应该修复
- INFO/LOW:代码异味或审计标记
规则应适用于所有文件,还是仅特定路径?Workflow 2: Vulnerability-Driven Generation
工作流2:漏洞驱动式生成
When given CVEs, CWEs, OWASP categories, or vulnerability descriptions:
- Research the vulnerability — use the research plan below to gather full context
- Parse the vulnerability — extract: affected language, vulnerable API/pattern, attack vector, fix
- Check existing rules — search and
semgrep-rules/for coveragesemgrep-rules-trailbits/ - Determine rule mode:
- Data flows from input to dangerous function → Taint mode
- Dangerous function call or config pattern → Search mode
- Text/config pattern without AST → Regex/generic mode
- Generate rule(s) — may produce multiple rules for different attack variants
- Present with explanation of what each rule catches and known limitations
当提供CVE、CWE、OWASP分类或漏洞描述时:
- 研究漏洞 — 使用以下研究计划收集完整上下文
- 解析漏洞 — 提取:受影响语言、漏洞API/模式、攻击向量、修复方案
- 检查现有规则 — 搜索和
semgrep-rules/查看覆盖情况semgrep-rules-trailbits/ - 确定规则模式:
- 数据从输入流向危险函数 → 污点模式
- 危险函数调用或配置模式 → 搜索模式
- 无AST的文本/配置模式 → 正则表达式/generic模式
- 生成规则 — 可能针对不同攻击变体生成多个规则
- 附带说明展示 — 说明每个规则捕获的内容及已知限制
Vulnerability Research Plan
漏洞研究计划
Before generating rules, conduct research to ensure comprehensive coverage. Use WebSearch and WebFetch tools.
Phase 1 — Understand the vulnerability:
- Search to get official descriptions
"<CVE/CWE ID>" vulnerability details - Search for real-world attack patterns
"<vulnerability type>" <language> exploit examples - Fetch the CWE entry from for taxonomy, related weaknesses, and detection methods
https://cwe.mitre.org/data/definitions/<ID>.html - Fetch the OWASP page for the relevant category (e.g., )
https://owasp.org/Top10/A03_2021-Injection/
Phase 2 — Map language-specific attack surface:
- Search
"<vulnerability>" <framework> cheat sheet site:cheatsheetseries.owasp.org - Search
"<vulnerability>" <framework> security best practices - Identify: entry points (sources), dangerous APIs (sinks), safe alternatives (sanitizers)
- Search to find real CVEs demonstrating the pattern
"<vulnerable function>" CVE
Phase 3 — Study existing detection:
- Search for community rules
semgrep rule "<vulnerability type>" <language> - Search existing rules in and
semgrep-rules/directoriessemgrep-rules-trailbits/ - Note what's covered and what gaps remain
Phase 4 — Document findings:
Write a brief research summary as a YAML comment block at the top of the rule file:
yaml
undefined生成规则前,请开展研究以确保覆盖全面。使用WebSearch和WebFetch工具。
阶段1 — 理解漏洞:
- 搜索获取官方描述
"<CVE/CWE ID>" vulnerability details - 搜索获取真实攻击模式
"<漏洞类型>" <语言> exploit examples - 从获取CWE条目,了解分类、相关弱点及检测方法
https://cwe.mitre.org/data/definitions/<ID>.html - 获取对应OWASP类别的页面(例如:)
https://owasp.org/Top10/A03_2021-Injection/
阶段2 — 映射语言特定攻击面:
- 搜索
"<漏洞>" <框架> cheat sheet site:cheatsheetseries.owasp.org - 搜索
"<漏洞>" <框架> security best practices - 确定:入口点(源头)、危险API(sink)、安全替代方案(净化器)
- 搜索查找展示该模式的真实CVE
"<危险函数>" CVE
阶段3 — 研究现有检测方案:
- 搜索获取社区规则
semgrep rule "<漏洞类型>" <语言> - 搜索和
semgrep-rules/目录中的现有规则semgrep-rules-trailbits/ - 记录已覆盖内容和存在的空白
阶段4 — 记录研究结果:
在规则文件顶部添加简短的研究摘要作为YAML注释块:
yaml
undefinedResearch: <vulnerability type> in <language/framework>
Research: <vulnerability type> in <language/framework>
Sources: <where untrusted data enters>
Sources: <where untrusted data enters>
Sinks: <where data becomes dangerous>
Sinks: <where data becomes dangerous>
Sanitizers: <what makes data safe>
Sanitizers: <what makes data safe>
References researched:
References researched:
- <url1>
- <url1>
- <url2>
- <url2>
Coverage gaps found: <what existing rules miss>
Coverage gaps found: <what existing rules miss>
undefinedundefinedMode Selection Guide
模式选择指南
| Vulnerability Type | Rule Mode | Why |
|---|---|---|
| SQL injection | Taint | User input → query function |
| XSS | Taint | User input → HTML output |
| Command injection | Taint | User input → exec/system |
| SSRF | Taint | User input → HTTP request |
| Path traversal | Taint | User input → file operation |
| Hardcoded secrets | Search + regex | Pattern match on literals |
| Insecure config | Search | Structural pattern on config |
| Missing auth checks | Search (inside/not-inside) | Absence of pattern |
| Race conditions | Search (inside + not-inside) | Pattern within goroutine/thread |
| Weak crypto | Search | Specific API calls |
| Deserialization | Search or Taint | Depends on if input-controlled |
| Terraform misconfig | Search | HCL structural patterns |
| 漏洞类型 | 规则模式 | 原因 |
|---|---|---|
| SQL注入 | Taint | 用户输入 → 查询函数 |
| XSS | Taint | 用户输入 → HTML输出 |
| 命令注入 | Taint | 用户输入 → exec/system |
| SSRF | Taint | 用户输入 → HTTP请求 |
| 路径遍历 | Taint | 用户输入 → 文件操作 |
| 硬编码密钥 | Search + regex | 字面量模式匹配 |
| 不安全配置 | Search | 配置结构化模式 |
| 缺少权限检查 | Search (inside/not-inside) | 模式缺失检测 |
| 竞态条件 | Search (inside + not-inside) | 协程/线程内模式检测 |
| 弱加密 | Search | 特定API调用检测 |
| 反序列化 | Search或Taint | 取决于是否由输入控制 |
| Terraform配置错误 | Search | HCL结构化模式 |
Rule Generation Template
规则生成模板
When generating a rule, always produce this complete structure:
yaml
rules:
- id: <company-or-project>-<language>-<vuln-type>
message: >-
<1-3 sentences: what was found, why it's dangerous, how to fix it>
severity: <ERROR|WARNING|INFO>
languages: [<language>]
metadata:
category: <security|correctness|best-practice|performance>
cwe:
- "CWE-XXX: <Description>"
owasp: # include if security rule
- "A0X:2021 - <Category>"
references:
- <url-to-documentation>
technology:
- <framework-or-library>
subcategory:
- <vuln|audit>
confidence: <HIGH|MEDIUM|LOW>
likelihood: <HIGH|MEDIUM|LOW>
impact: <HIGH|MEDIUM|LOW>
# ... pattern operators or taint spec ...生成规则时,请始终遵循以下完整结构:
yaml
rules:
- id: <company-or-project>-<language>-<vuln-type>
message: >-
<1-3句话:检测到什么,为何危险,如何修复>
severity: <ERROR|WARNING|INFO>
languages: [<language>]
metadata:
category: <security|correctness|best-practice|performance>
cwe:
- "CWE-XXX: <Description>"
owasp: # 安全规则需包含
- "A0X:2021 - <Category>"
references:
- <url-to-documentation>
technology:
- <framework-or-library>
subcategory:
- <vuln|audit>
confidence: <HIGH|MEDIUM|LOW>
likelihood: <HIGH|MEDIUM|LOW>
impact: <HIGH|MEDIUM|LOW>
# ... pattern operators or taint spec ...Naming Convention
命名规范
Rule IDs:
<scope>-<language>-<vuln-type>[-<variant>]myapp-python-sql-injectionmyapp-go-race-condition-map-writemyapp-java-spring-ssrf
规则ID:
<scope>-<language>-<vuln-type>[-<variant>]myapp-python-sql-injectionmyapp-go-race-condition-map-writemyapp-java-spring-ssrf
Message Quality
消息质量要求
Good messages include:
- What was detected (the pattern)
- Why it's dangerous (the risk)
- How to fix it (the remediation)
yaml
message: >-
User input from `flask.request` is concatenated into a SQL query string
passed to `cursor.execute()`. This could allow SQL injection, letting an
attacker read or modify database contents. Use parameterized queries instead:
`cursor.execute("SELECT * FROM users WHERE id = %s", (user_id,))`.优质消息应包含:
- 检测内容(模式是什么)
- 危险原因(风险是什么)
- 修复方法(补救措施)
yaml
message: >-
来自`flask.request`的用户输入被拼接进SQL查询字符串并传递给`cursor.execute()`。这可能导致SQL注入,让攻击者读取或修改数据库内容。请改用参数化查询:
`cursor.execute("SELECT * FROM users WHERE id = %s", (user_id,))`。Test File Generation
测试文件生成
Always generate a companion test file with:
python
undefined始终生成配套测试文件,包含:
python
undefined=== True Positives (MUST trigger) ===
=== 真阳性(必须触发规则)===
ruleid: <rule-id>
ruleid: <rule-id>
<vulnerable code example 1>
<漏洞代码示例1>
ruleid: <rule-id>
ruleid: <rule-id>
<vulnerable code example 2 — different variant>
<漏洞代码示例2 — 不同变体>
=== True Negatives (must NOT trigger) ===
=== 真阴性(必须不触发规则)===
ok: <rule-id>
ok: <rule-id>
<safe code — using the recommended fix>
<安全代码 — 使用推荐修复方案>
ok: <rule-id>
ok: <rule-id>
<safe code — different safe pattern>
**Minimum:** 2 true positives + 2 true negatives per rule.<安全代码 — 不同安全模式>
**最低要求:** 每个规则至少2个真阳性 + 2个真阴性用例。Advanced Patterns Cookbook
高级模式手册
Detect missing security check (pattern-not-inside)
检测缺失的安全检查(pattern-not-inside)
yaml
patterns:
- pattern: dangerous_operation(...)
- pattern-not-inside: |
if <... auth_check(...) ...>:
...yaml
patterns:
- pattern: dangerous_operation(...)
- pattern-not-inside: |
if <... auth_check(...) ...>:
...Detect tainted string concatenation (taint + metavariable-regex)
检测受污染的字符串拼接(taint + metavariable-regex)
yaml
mode: taint
pattern-sources:
- pattern: request.args.get(...)
pattern-sinks:
- patterns:
- pattern: |
"$SQLSTR" + ...
- metavariable-regex:
metavariable: $SQLSTR
regex: \s*(?i)(select|delete|insert|create|update|alter|drop)\b.*yaml
mode: taint
pattern-sources:
- pattern: request.args.get(...)
pattern-sinks:
- patterns:
- pattern: |
"$SQLSTR" + ...
- metavariable-regex:
metavariable: $SQLSTR
regex: \s*(?i)(select|delete|insert|create|update|alter|drop)\b.*Detect weak config values (metavariable-comparison)
检测弱配置值(metavariable-comparison)
yaml
patterns:
- pattern-inside: |
resource "aws_s3_bucket" "..." {
...
versioning { days = $DAYS }
...
}
- metavariable-comparison:
metavariable: $DAYS
comparison: $DAYS < 90yaml
patterns:
- pattern-inside: |
resource "aws_s3_bucket" "..." {
...
versioning { days = $DAYS }
...
}
- metavariable-comparison:
metavariable: $DAYS
comparison: $DAYS < 90Detect across multiple call variants (pattern-either + metavariable-regex)
检测多调用变体(pattern-either + metavariable-regex)
yaml
patterns:
- pattern-either:
- pattern: $OBJ.$METHOD(...)
- pattern: $MODULE.$METHOD(...)
- metavariable-regex:
metavariable: $METHOD
regex: (eval|exec|compile|unsafe_load)yaml
patterns:
- pattern-either:
- pattern: $OBJ.$METHOD(...)
- pattern: $MODULE.$METHOD(...)
- metavariable-regex:
metavariable: $METHOD
regex: (eval|exec|compile|unsafe_load)Detect with type constraints (typed metavariables)
带类型约束的检测(类型化元变量)
yaml
undefinedyaml
undefinedGo: match only http.Request types
Go: 仅匹配http.Request类型
pattern: ($REQ : *http.Request).$FIELD
undefinedpattern: ($REQ : *http.Request).$FIELD
undefinedMulti-step taint with labels
带标签的多步骤污点分析
yaml
mode: taint
pattern-sources:
- patterns:
- pattern: request.get_param(...)
label: USER_INPUT
- patterns:
- pattern: $X + $Y
label: CONCATENATED
requires: USER_INPUT
pattern-sinks:
- patterns:
- pattern: db.execute(...)
requires: CONCATENATEDyaml
mode: taint
pattern-sources:
- patterns:
- pattern: request.get_param(...)
label: USER_INPUT
- patterns:
- pattern: $X + $Y
label: CONCATENATED
requires: USER_INPUT
pattern-sinks:
- patterns:
- pattern: db.execute(...)
requires: CONCATENATEDReducing False Positives
减少误报
After generating a rule, always consider adding:
- pattern-not — exclude safe variants (for literal strings)
pattern-not: func("...", ...) - pattern-not-inside — exclude safe contexts (inside try/catch, inside sanitization wrapper)
- metavariable-regex — restrict metavariable values to dangerous ones
- Safe type exclusions —
options: { taint_assume_safe_numbers: true, taint_assume_safe_booleans: true } - Log/print exclusions — to avoid flagging logging
pattern-not-inside: $LOG.info(...)
生成规则后,请始终考虑添加:
- pattern-not — 排除安全变体(如针对字面量字符串的)
pattern-not: func("...", ...) - pattern-not-inside — 排除安全上下文(如try/catch块内、净化包装器内)
- metavariable-regex — 限制元变量值为危险内容
- 安全类型排除 —
options: { taint_assume_safe_numbers: true, taint_assume_safe_booleans: true } - 日志/打印排除 — 避免标记日志代码
pattern-not-inside: $LOG.info(...)
Validation Checklist
验证 checklist
Before finalizing any rule:
- Rule ID is unique and follows kebab-case
- field matches the target code
languages - Message explains what, why, and how-to-fix
- Metadata includes CWE and OWASP where applicable
- At least 2 true positive test cases
- At least 2 true negative test cases
- False positive reducers considered (pattern-not, safe type options)
- Rule tested with if available
opengrep scan --config <rule.yaml> <test-file>
最终确定规则前,请检查:
- 规则ID唯一且遵循kebab-case命名法
- 字段与目标代码匹配
languages - 消息说明白检测内容、危险原因及修复方法
- 元数据包含适用的CWE和OWASP信息
- 至少2个真阳性测试用例
- 至少2个真阴性测试用例
- 已考虑误报减少措施(pattern-not、安全类型选项)
- 若可行,已使用测试规则
opengrep scan --config <rule.yaml> <test-file>
Batch Generation
批量生成
When asked to generate rules for a class of vulnerabilities (e.g., "OWASP Top 10 for Python Flask"):
- List all applicable vulnerability categories
- Check existing coverage in
semgrep-rules/ - Identify gaps
- Generate rules for gaps only
- Present as a table: | Vulnerability | Existing Rule? | New Rule ID | Mode |
当要求为某类漏洞生成规则时(例如:“Python Flask的OWASP Top 10规则”):
- 列出所有适用的漏洞类别
- 检查中的现有覆盖情况
semgrep-rules/ - 识别空白区域
- 仅为空白区域生成规则
- 以表格形式展示:| 漏洞 | 已有规则? | 新规则ID | 模式 |
Rule Generation Methodology
规则生成方法论
Follow this systematic process to generate high-quality rules:
遵循以下系统化流程生成高质量规则:
1. Understand the Vulnerability Deeply
1. 深入理解漏洞
Don't just pattern-match on function names. Understand:
- What makes it dangerous? (the root cause, not the symptom)
- What's the attack scenario? (how does an attacker exploit this?)
- What's the data flow? (source → transformation → sink)
- What are ALL the variants? (string concat, format strings, template literals, f-strings)
- What are the safe alternatives? (parameterized queries, template engines, escaping functions)
不要仅匹配函数名。 需理解:
- 为何危险?(根本原因,而非表面症状)
- 攻击场景是什么?(攻击者如何利用?)
- 数据流是怎样的?(源头 → 转换 → sink)
- 所有变体有哪些?(字符串拼接、格式化字符串、模板字面量、f-strings)
- 安全替代方案是什么?(参数化查询、模板引擎、转义函数)
2. Study Existing Rules as Templates
2. 以现有规则为模板学习
Before writing from scratch, search existing rules for similar patterns:
semgrep-rules/semgrep-rules/<language>/<framework>/security/
semgrep-rules-trailbits/<language>/Read the best-quality rules and adapt their patterns. Existing rules show:
- Which sources are standard for each framework
- Which metavariable-regex patterns reduce false positives
- How pattern-not exclusions are structured
- What metadata fields and CWE/OWASP mappings to use
从零开始编写前,搜索现有规则查找类似模式:
semgrep-rules/semgrep-rules/<language>/<framework>/security/
semgrep-rules-trailbits/<language>/阅读高质量规则并调整其模式。现有规则展示:
- 各框架的标准源头
- 哪些metavariable-regex模式可减少误报
- pattern-not排除的结构
- 应使用哪些元数据字段及CWE/OWASP映射
3. Build Source-Sink-Sanitizer Maps
3. 构建源头-Sink-净化器映射
For each language/framework, document:
| Component | Examples |
|---|---|
| Sources (user input entry points) | |
| Sinks (dangerous output points) | |
| Sanitizers (safe transformations) | |
| Propagators (data structure flow) | |
为每种语言/框架记录:
| 组件 | 示例 |
|---|---|
| 源头(用户输入入口) | |
| Sink(危险输出点) | |
| 净化器(安全转换操作) | |
| 传播器(数据结构流动) | |
4. Apply Defense-in-Depth Pattern Writing
4. 应用纵深防御模式编写
Write rules in layers:
- Broad taint rule — catches the primary attack vector
- Specific search rules — catches dangerous API misuse (e.g., )
dangerouslySetInnerHTML - Config/audit rules — flags risky configurations (e.g., )
autoescape off
分层编写规则:
- 宽泛污点规则 — 捕获主要攻击向量
- 特定搜索规则 — 捕获危险API误用(如)
dangerouslySetInnerHTML - 配置/审计规则 — 标记风险配置(如)
autoescape off
5. Iterate on False Positive Reduction
5. 迭代减少误报
After initial rule generation:
- Think through common safe patterns that would trigger
- Add for safe literals, safe types, logging
pattern-not - Add for try/catch, validation wrappers
pattern-not-inside - Set and
taint_assume_safe_numbers: truetaint_assume_safe_booleans: true - Use to restrict to dangerous method names
metavariable-regex
初始规则生成后:
- 思考可能触发规则的常见安全模式
- 添加针对安全字面量、安全类型、日志的
pattern-not - 添加针对try/catch、验证包装器的
pattern-not-inside - 设置和
taint_assume_safe_numbers: truetaint_assume_safe_booleans: true - 使用限制危险方法名
metavariable-regex
Full Context: Reference Documentation
完整上下文:参考文档
When generating rules, these docs contain the complete rule schema:
| What You Need | Where to Find It |
|---|---|
| All pattern operators | |
| Taint mode spec (sources/sinks/sanitizers/propagators/labels) | |
| Metavariable conditions (regex, comparison, type, pattern) | |
| All supported languages | |
| Rule templates (8 complete examples) | |
| How the engine matches patterns | |
| How taint analysis works internally | |
| Existing rule coverage by language | |
| CWE/OWASP metadata conventions | |
| Rule options (engine config) | |
生成规则时,以下文档包含完整规则 schema:
| 需要的内容 | 查找位置 |
|---|---|
| 所有模式运算符 | |
| 污点模式规范(源头/sink/净化器/传播器/标签) | |
| 元变量条件(正则、比较、类型、模式) | |
| 所有支持的语言 | |
| 规则模板(8个完整示例) | |
| 引擎匹配模式的方式 | |
| 污点分析内部工作原理 | |
| 按语言划分的现有规则覆盖情况 | |
| CWE/OWASP元数据约定 | |
| 规则选项(引擎配置) | |
Generated Rules Directory
生成规则存储目录
Store generated rules in with companion test files:
custom-rules/<vuln-type>/custom-rules/
xss/
xss-python-flask.yaml # Rules
xss-python-flask.py # Test file
sqli/
sqli-java-spring.yaml
sqli-java-spring.java将生成的规则存储在目录下,并附带测试文件:
custom-rules/<vuln-type>/custom-rules/
xss/
xss-python-flask.yaml # 规则文件
xss-python-flask.py # 测试文件
sqli/
sqli-java-spring.yaml
sqli-java-spring.javaCommon Mistakes to Avoid
需避免的常见错误
| Mistake | Fix |
|---|---|
Pattern too broad ( | Add |
| Missing ellipsis in function bodies | Use |
Forgetting | Always consider: what does the SAFE code look like? |
| Wrong language ID | Check docs/ai/RULES_SYNTAX.md Section 9 for valid IDs |
| Taint without sanitizers | Always ask: what makes this data safe? Add sanitizers. |
| Hardcoding framework versions | Use |
| Not testing negatives | False positives destroy trust — test safe code paths |
| 错误 | 修复方案 |
|---|---|
模式过于宽泛( | 添加 |
| 函数体中缺少省略号 | 在函数/类体中使用 |
忘记为安全变体添加 | 始终思考:安全代码是什么样的? |
| 错误的语言ID | 查看docs/ai/RULES_SYNTAX.md第9节获取有效ID |
| 污点模式未包含净化器 | 始终询问:什么能让数据变得安全?添加净化器。 |
| 硬编码框架版本 | 使用 |
| 未测试阴性用例 | 误报会破坏信任 — 测试安全代码路径 |