opengrep-rule-generator

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Opengrep 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:
DocPathLoad When
Rule syntax & templates
docs/ai/RULES_SYNTAX.md
Always — contains all operators, templates, language IDs
Rule index
docs/ai/RULES_INDEX.md
When checking for existing similar rules
Engine internals
docs/ai/RULES_ENGINE.md
When choosing between search vs taint mode
Also search existing rules for similar patterns:
  • semgrep-rules/semgrep-rules/<language>/
    — community rules
  • semgrep-rules-trailbits/<language>/
    — Trail of Bits rules
生成任何规则前,请从以下项目文档加载上下文:
文档路径加载时机
规则语法与模板
docs/ai/RULES_SYNTAX.md
始终加载 — 包含所有运算符、模板、语言ID
规则索引
docs/ai/RULES_INDEX.md
检查是否存在类似规则时加载
引擎内部机制
docs/ai/RULES_ENGINE.md
选择搜索模式与污点模式时加载
同时搜索现有规则以查找类似模式:
  • semgrep-rules/semgrep-rules/<language>/
    — 社区规则
  • semgrep-rules-trailbits/<language>/
    — Trail of Bits规则

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:
  1. Research the vulnerability — use the research plan below to gather full context
  2. Parse the vulnerability — extract: affected language, vulnerable API/pattern, attack vector, fix
  3. Check existing rules — search
    semgrep-rules/
    and
    semgrep-rules-trailbits/
    for coverage
  4. 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
  5. Generate rule(s) — may produce multiple rules for different attack variants
  6. Present with explanation of what each rule catches and known limitations
当提供CVE、CWE、OWASP分类或漏洞描述时:
  1. 研究漏洞 — 使用以下研究计划收集完整上下文
  2. 解析漏洞 — 提取:受影响语言、漏洞API/模式、攻击向量、修复方案
  3. 检查现有规则 — 搜索
    semgrep-rules/
    semgrep-rules-trailbits/
    查看覆盖情况
  4. 确定规则模式
    • 数据从输入流向危险函数 → 污点模式
    • 危险函数调用或配置模式 → 搜索模式
    • 无AST的文本/配置模式 → 正则表达式/generic模式
  5. 生成规则 — 可能针对不同攻击变体生成多个规则
  6. 附带说明展示 — 说明每个规则捕获的内容及已知限制

Vulnerability Research Plan

漏洞研究计划

Before generating rules, conduct research to ensure comprehensive coverage. Use WebSearch and WebFetch tools.
Phase 1 — Understand the vulnerability:
  • Search
    "<CVE/CWE ID>" vulnerability details
    to get official descriptions
  • Search
    "<vulnerability type>" <language> exploit examples
    for real-world attack patterns
  • Fetch the CWE entry from
    https://cwe.mitre.org/data/definitions/<ID>.html
    for taxonomy, related weaknesses, and detection methods
  • 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
    "<vulnerable function>" CVE
    to find real CVEs demonstrating the pattern
Phase 3 — Study existing detection:
  • Search
    semgrep rule "<vulnerability type>" <language>
    for community rules
  • Search existing rules in
    semgrep-rules/
    and
    semgrep-rules-trailbits/
    directories
  • 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
    获取真实攻击模式
  • https://cwe.mitre.org/data/definitions/<ID>.html
    获取CWE条目,了解分类、相关弱点及检测方法
  • 获取对应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
undefined

Research: <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>

undefined
undefined

Mode Selection Guide

模式选择指南

Vulnerability TypeRule ModeWhy
SQL injectionTaintUser input → query function
XSSTaintUser input → HTML output
Command injectionTaintUser input → exec/system
SSRFTaintUser input → HTTP request
Path traversalTaintUser input → file operation
Hardcoded secretsSearch + regexPattern match on literals
Insecure configSearchStructural pattern on config
Missing auth checksSearch (inside/not-inside)Absence of pattern
Race conditionsSearch (inside + not-inside)Pattern within goroutine/thread
Weak cryptoSearchSpecific API calls
DeserializationSearch or TaintDepends on if input-controlled
Terraform misconfigSearchHCL structural patterns
漏洞类型规则模式原因
SQL注入Taint用户输入 → 查询函数
XSSTaint用户输入 → HTML输出
命令注入Taint用户输入 → exec/system
SSRFTaint用户输入 → HTTP请求
路径遍历Taint用户输入 → 文件操作
硬编码密钥Search + regex字面量模式匹配
不安全配置Search配置结构化模式
缺少权限检查Search (inside/not-inside)模式缺失检测
竞态条件Search (inside + not-inside)协程/线程内模式检测
弱加密Search特定API调用检测
反序列化Search或Taint取决于是否由输入控制
Terraform配置错误SearchHCL结构化模式

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-injection
  • myapp-go-race-condition-map-write
  • myapp-java-spring-ssrf
规则ID:
<scope>-<language>-<vuln-type>[-<variant>]
  • myapp-python-sql-injection
  • myapp-go-race-condition-map-write
  • myapp-java-spring-ssrf

Message Quality

消息质量要求

Good messages include:
  1. What was detected (the pattern)
  2. Why it's dangerous (the risk)
  3. 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,))`.
优质消息应包含:
  1. 检测内容(模式是什么)
  2. 危险原因(风险是什么)
  3. 修复方法(补救措施)
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 < 90
yaml
patterns:
  - pattern-inside: |
      resource "aws_s3_bucket" "..." {
        ...
        versioning { days = $DAYS }
        ...
      }
  - metavariable-comparison:
      metavariable: $DAYS
      comparison: $DAYS < 90

Detect 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
undefined
yaml
undefined

Go: match only http.Request types

Go: 仅匹配http.Request类型

pattern: ($REQ : *http.Request).$FIELD
undefined
pattern: ($REQ : *http.Request).$FIELD
undefined

Multi-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: CONCATENATED
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: CONCATENATED

Reducing False Positives

减少误报

After generating a rule, always consider adding:
  1. pattern-not — exclude safe variants (
    pattern-not: func("...", ...)
    for literal strings)
  2. pattern-not-inside — exclude safe contexts (inside try/catch, inside sanitization wrapper)
  3. metavariable-regex — restrict metavariable values to dangerous ones
  4. Safe type exclusions
    options: { taint_assume_safe_numbers: true, taint_assume_safe_booleans: true }
  5. Log/print exclusions
    pattern-not-inside: $LOG.info(...)
    to avoid flagging logging
生成规则后,请始终考虑添加:
  1. pattern-not — 排除安全变体(如针对字面量字符串的
    pattern-not: func("...", ...)
  2. pattern-not-inside — 排除安全上下文(如try/catch块内、净化包装器内)
  3. metavariable-regex — 限制元变量值为危险内容
  4. 安全类型排除
    options: { taint_assume_safe_numbers: true, taint_assume_safe_booleans: true }
  5. 日志/打印排除
    pattern-not-inside: $LOG.info(...)
    避免标记日志代码

Validation Checklist

验证 checklist

Before finalizing any rule:
  • Rule ID is unique and follows kebab-case
  • languages
    field matches the target code
  • 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
    opengrep scan --config <rule.yaml> <test-file>
    if available
最终确定规则前,请检查:
  • 规则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"):
  1. List all applicable vulnerability categories
  2. Check existing coverage in
    semgrep-rules/
  3. Identify gaps
  4. Generate rules for gaps only
  5. Present as a table: | Vulnerability | Existing Rule? | New Rule ID | Mode |
当要求为某类漏洞生成规则时(例如:“Python Flask的OWASP Top 10规则”):
  1. 列出所有适用的漏洞类别
  2. 检查
    semgrep-rules/
    中的现有覆盖情况
  3. 识别空白区域
  4. 仅为空白区域生成规则
  5. 以表格形式展示:| 漏洞 | 已有规则? | 新规则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:
ComponentExamples
Sources (user input entry points)
request.args
,
req.query
,
$_GET
,
params[:]
Sinks (dangerous output points)
res.send()
,
echo
,
innerHTML
,
cursor.execute()
Sanitizers (safe transformations)
escape()
,
htmlspecialchars()
,
parseInt()
, template engines
Propagators (data structure flow)
StringBuilder.append()
,
HashMap.put()
,
array.push()
为每种语言/框架记录:
组件示例
源头(用户输入入口)
request.args
,
req.query
,
$_GET
,
params[:]
Sink(危险输出点)
res.send()
,
echo
,
innerHTML
,
cursor.execute()
净化器(安全转换操作)
escape()
,
htmlspecialchars()
,
parseInt()
, 模板引擎
传播器(数据结构流动)
StringBuilder.append()
,
HashMap.put()
,
array.push()

4. Apply Defense-in-Depth Pattern Writing

4. 应用纵深防御模式编写

Write rules in layers:
  1. Broad taint rule — catches the primary attack vector
  2. Specific search rules — catches dangerous API misuse (e.g.,
    dangerouslySetInnerHTML
    )
  3. Config/audit rules — flags risky configurations (e.g.,
    autoescape off
    )
分层编写规则:
  1. 宽泛污点规则 — 捕获主要攻击向量
  2. 特定搜索规则 — 捕获危险API误用(如
    dangerouslySetInnerHTML
  3. 配置/审计规则 — 标记风险配置(如
    autoescape off

5. Iterate on False Positive Reduction

5. 迭代减少误报

After initial rule generation:
  1. Think through common safe patterns that would trigger
  2. Add
    pattern-not
    for safe literals, safe types, logging
  3. Add
    pattern-not-inside
    for try/catch, validation wrappers
  4. Set
    taint_assume_safe_numbers: true
    and
    taint_assume_safe_booleans: true
  5. Use
    metavariable-regex
    to restrict to dangerous method names
初始规则生成后:
  1. 思考可能触发规则的常见安全模式
  2. 添加针对安全字面量、安全类型、日志的
    pattern-not
  3. 添加针对try/catch、验证包装器的
    pattern-not-inside
  4. 设置
    taint_assume_safe_numbers: true
    taint_assume_safe_booleans: true
  5. 使用
    metavariable-regex
    限制危险方法名

Full Context: Reference Documentation

完整上下文:参考文档

When generating rules, these docs contain the complete rule schema:
What You NeedWhere to Find It
All pattern operators
docs/ai/RULES_SYNTAX.md
§3-5
Taint mode spec (sources/sinks/sanitizers/propagators/labels)
docs/ai/RULES_SYNTAX.md
§6
Metavariable conditions (regex, comparison, type, pattern)
docs/ai/RULES_SYNTAX.md
§4
All supported languages
docs/ai/RULES_SYNTAX.md
§9
Rule templates (8 complete examples)
docs/ai/RULES_SYNTAX.md
§12
How the engine matches patterns
docs/ai/RULES_ENGINE.md
§2
How taint analysis works internally
docs/ai/RULES_ENGINE.md
§3
Existing rule coverage by language
docs/ai/RULES_INDEX.md
CWE/OWASP metadata conventions
docs/ai/RULES_SYNTAX.md
§7
Rule options (engine config)
docs/ai/RULES_SYNTAX.md
§8
生成规则时,以下文档包含完整规则 schema:
需要的内容查找位置
所有模式运算符
docs/ai/RULES_SYNTAX.md
§3-5
污点模式规范(源头/sink/净化器/传播器/标签)
docs/ai/RULES_SYNTAX.md
§6
元变量条件(正则、比较、类型、模式)
docs/ai/RULES_SYNTAX.md
§4
所有支持的语言
docs/ai/RULES_SYNTAX.md
§9
规则模板(8个完整示例)
docs/ai/RULES_SYNTAX.md
§12
引擎匹配模式的方式
docs/ai/RULES_ENGINE.md
§2
污点分析内部工作原理
docs/ai/RULES_ENGINE.md
§3
按语言划分的现有规则覆盖情况
docs/ai/RULES_INDEX.md
CWE/OWASP元数据约定
docs/ai/RULES_SYNTAX.md
§7
规则选项(引擎配置)
docs/ai/RULES_SYNTAX.md
§8

Generated Rules Directory

生成规则存储目录

Store generated rules in
custom-rules/<vuln-type>/
with companion test files:
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.java

Common Mistakes to Avoid

需避免的常见错误

MistakeFix
Pattern too broad (
$FUNC(...)
)
Add
metavariable-regex
or
pattern-inside
to constrain
Missing ellipsis in function bodiesUse
...
in function/class bodies for flexible matching
Forgetting
pattern-not
for safe variants
Always consider: what does the SAFE code look like?
Wrong language IDCheck docs/ai/RULES_SYNTAX.md Section 9 for valid IDs
Taint without sanitizersAlways ask: what makes this data safe? Add sanitizers.
Hardcoding framework versionsUse
...
for version-agnostic patterns
Not testing negativesFalse positives destroy trust — test safe code paths
错误修复方案
模式过于宽泛(
$FUNC(...)
添加
metavariable-regex
pattern-inside
进行约束
函数体中缺少省略号在函数/类体中使用
...
实现灵活匹配
忘记为安全变体添加
pattern-not
始终思考:安全代码是什么样的?
错误的语言ID查看docs/ai/RULES_SYNTAX.md第9节获取有效ID
污点模式未包含净化器始终询问:什么能让数据变得安全?添加净化器。
硬编码框架版本使用
...
实现版本无关的模式
未测试阴性用例误报会破坏信任 — 测试安全代码路径