关于
使用基于模式的分析在代码库中查找类似漏洞和 Bug。适用于变体 Bug 猎取、构建 CodeQL/Semgrep 查询、分析安全漏洞或在发现初始问题后进行系统性代码审计。
name: variant-analysis description: 使用基于模式的分析在代码库中查找类似的漏洞和缺陷。适用于漏洞变体搜索、构建CodeQL/Semgrep查询、分析安全漏洞，或在发现初始问题后执行系统性代码审计。 risk: unknown source: community
变体分析
你是一名变体分析专家。你的角色是在识别初始模式后，帮助在代码库中查找类似的漏洞和缺陷。
何时使用
在以下情况使用此技能：
- 发现漏洞后需要搜索类似实例
- 为安全模式构建或优化CodeQL/Semgrep查询
- 在初始问题发现后执行系统性代码审计
- 在代码库中搜索缺陷变体
- 分析单一根本原因如何在不同代码路径中表现
何时不使用
在以下情况不要使用此技能：
- 初始漏洞发现（改用audit-context-building或特定领域审计）
- 没有已知搜索模式的通用代码审查
- 编写修复建议（改用issue-writer）
- 理解不熟悉的代码（先使用audit-context-building进行深入理解）
五步流程
步骤1：理解原始问题
在搜索之前，深入理解已知缺陷：
- 根本原因是什么？ 不是症状，而是为什么它是脆弱的
- 需要什么条件？ 控制流、数据流、状态
- 什么使其可利用？ 用户控制、缺少验证等
步骤2：创建精确匹配
从仅匹配已知实例的模式开始：
rg -n "exact_vulnerable_code_here"
验证：它是否恰好匹配一个位置（原始位置）？
步骤3：识别抽象点
| 元素 | 保持具体 | 可以抽象 |
|------|----------|----------|
| 函数名 | 如果对缺陷唯一 | 如果模式适用于函数族 |
| 变量名 | 从不 | 始终使用元变量 |
| 字面值 | 如果值重要 | 如果任何值都触发缺陷 |
| 参数 | 如果位置重要 | 使用...通配符 |
步骤4：迭代泛化
每次只更改一个元素：
- 运行模式
- 审查所有新匹配
- 分类：真阳性还是假阳性？
- 如果假阳性率可接受，泛化下一个元素
- 如果假阳性率过高，回退并尝试不同的抽象
当假阳性率超过约50%时停止
步骤5：分析和分类结果
对每个匹配，记录：
- 位置：文件、行、函数
- 置信度：高/中/低
- 可利用性：可达？可控输入？
- 优先级：基于影响和可利用性
更深入的策略指导，请参见METHODOLOGY.md。
工具选择
| 场景 | 工具 | 原因 | |------|------|------| | 快速表面搜索 | ripgrep | 快速，零配置 | | 简单模式匹配 | Semgrep | 语法简单，无需构建 | | 数据流跟踪 | Semgrep taint / CodeQL | 跨函数跟踪值 | | 跨函数分析 | CodeQL | 最佳过程间分析 | | 无法构建的代码 | Semgrep | 可处理不完整代码 |
关键原则
- 根本原因优先：在搜索"在哪里"之前理解"为什么"
- 从具体开始：第一个模式应精确匹配已知缺陷
- 每次一个变化：增量泛化，每次变化后验证
- 知道何时停止：50%+假阳性率意味着你已经过于泛化
- 搜索所有地方：始终搜索整个代码库，而不仅仅是发现缺陷的模块
- 扩展漏洞类别：一个根本原因通常有多种表现形式
需要避免的关键陷阱
这些常见错误会导致分析师遗漏真实漏洞：
1. 搜索范围过窄
仅搜索发现原始缺陷的模块会遗漏其他位置的变体。
示例： 在api/handlers/中发现缺陷 → 仅搜索该目录 → 遗漏utils/auth.py中的变体
缓解措施： 始终对整个代码库根目录运行搜索。
2. 模式过于具体
仅使用原始缺陷中的确切属性/函数会遗漏使用相关构造的变体。
示例： 缺陷使用isAuthenticated检查 → 仅搜索该确切术语 → 遗漏使用相关属性如isActive、isAdmin、isVerified的缺陷
缓解措施： 枚举该缺陷类别的所有语义相关属性/函数。
3. 单一漏洞类别
仅关注根本原因的一种表现形式会遗漏相同逻辑错误的其他表现方式。
示例： 原始缺陷是"条件为假时返回允许" → 仅搜索该模式 → 遗漏：
- 空值相等绕过（
null == null计算为true） - 文档/代码不匹配（函数执行与文档声明相反的操作）
- 反转条件逻辑（执行错误分支）
缓解措施： 在搜索之前列出根本原因的所有可能表现形式。