analyze-findings

技能：分析发现结果

一个 finding 文件汇总了某条规则的所有结果。阅读每个结果的代码流，将汇总内容拆分为不同漏洞，并根据各自的证据分别给出 TP/FP 判定

输入

由调用方提供；未提供时使用默认值。只有缺少必需输入且没有合理默认值时才追问

• project-root（可选）— 目标项目的根目录。Opentaint 将所有分析产物保存在固定的 <project-root>/.opentaint/ 目录下，因此下文所有 .opentaint/... 路径均相对于该目录解析。默认值：当前目录
• language（必需）— 该项目的目标语言及语言专属说明
• findings（必需）— 待分类的 finding 文件；每个 .opentaint/tracking/findings/<name>.yaml 文件会在 sarif_hashes 中汇总某条规则的 SARIF 结果

工作流

1. 判定前先核对

如果某个 finding 的 notes 以 reconcile 行开头，那么它是某条规则下的重新扫描结果，该规则的其他 finding 已完成分类——通常是同一漏洞的哈希发生了变化，而非新漏洞。将其作为新结果判定前，先阅读该规则下已分类的 finding 文件并比较代码流（源 → 汇点，核心路径相同）：如果找到匹配项，就将此 finding 的 sarif_hashes 移入该 finding，删除此文件，并沿用已有判定——不要重新判定已分类过的代码流。只有在找不到匹配的已分类 finding 时，才将其视为新结果并继续执行以下步骤。

2. 一次处理一个结果——STOP 检查清单

对汇总中的每个哈希，在给出任何判定前，从 .opentaint/results/report.sarif 读取其原始结果：

• 通过 sarif_hashes 查找对应的 SARIF 结果——每个条目都是该结果 vulnerabilitySourceSinkHash/vulnerabilityWithTraceHash 指纹的前 16 个字符，因此要与结果的 fingerprints/partialFingerprints 匹配——然后读取原始 codeFlows[]
• 遍历每个步骤，沿着源 → 中间跳转 → 汇点确认端到端传递的是同一个污点值；结合应用源码（构建项目自身位于 .opentaint/project/sources/ 下的源码）和依赖代码核实代码流，不要只依赖跟踪文本
• 根据每个结果自身的跟踪分别判定——不能仅仅因为多个结果共享同一条规则，就让它们共享判定

3. 将汇总拆分为逻辑 finding

文件中的结果都触发了同一条规则，但可能对应多个不同漏洞。属于同一漏洞的结果（汇点相同，核心代码流相同）应归为一个 finding；将真正不同的结果移入各自的新 finding 文件，并填写其 sarif_hashes（参见 Tracking）。

4. 分类并记录

根据代码流为每个逻辑 finding 判定：

• TP — 来源由攻击者控制，带有该输入的汇点确实危险，且中间没有任何净化处理
• FP — 净化器/验证器消除了风险、来源实际上并非由攻击者控制（配置、常量、服务器设置）、汇点对该输入是安全的（参数化、转义），或路径不可行。记录具体原因

设置 verdict，并在已有的分析器报告下方将判定理由追加到 notes（参见 Tracking）。

输出

产物

• .opentaint/tracking/findings/<name>.yaml — 每个已分类的 finding 均设置了 verdict，并在 notes 中追加理由；拆分时还会写入新的 finding 文件（参见 Tracking）

摘要

• 每个 finding 一行：名称、判定结果、一句简短理由

跟踪

此技能只会写入每条发现的 verdict，并将推理追加到 notes。拆分时还会创建一个新的发现文件——使用新的类 Docker 名称、迁移过来的 sarif_hashes，并复制该组合中的 rule_id；同时将初始分析器报告写入其 notes，并让 poc 保持待处理状态。切勿修改 poc 字段，也不要修改保留的发现中的 sarif_hashes。

.opentaint/tracking/findings/<name>.yaml — 一条发现，将某条规则的 SARIF 结果归为一组，并在分类和 PoC 阶段持续跟踪。脚本会根据扫描结果为每个文件写入初始内容，包括 sarif_hashes、rule_id 和 notes 中的分析器报告。分类阶段设置 verdict 并追加推理。PoC 阶段设置 poc 并追加结果。通过注释保持清晰

sarif_hashes: [a1b2c3d4, e5f6a7b8]
rule_id: <language>/security/sql-injection.yaml:sql-injection
verdict: TP
notes: >
  <analyzer report for these results — seeded from the scan>
  triage: the request's order field is attacker-controlled and reaches raw query construction → TP
  poc: a crafted order value produced the expected database delay → confirmed
poc: confirmed

约束

• 仅在发现文件中填写判定和备注——绝不写入 .opentaint/vulnerabilities.md；协调器会根据判定汇总生成该文件
• 根据每条结果自身的跟踪信息进行判断，绝不要仅仅因为它们触发了相同的规则，就对多条结果给出相同的判定

注意事项

• 批量判定是分类中最常见的错误——未阅读跟踪信息，就用同一条理由标记多条结果
• 一条规则的结果组合并不等于一条发现——应拆分不同的漏洞，但真正重复的结果（汇点和数据流相同）应合并为一条发现，并包含多个 sarif_hashes