vulnerability-triage-brocards

漏洞分诊准则

在投入资源进行深入分析之前，依据 7 项原则性标准系统评估收到的漏洞报告。每项准则都是可证伪的测试：如果报告未通过任何一项准则，记录原因并予以驳回或请求澄清。如果报告通过全部 7 项准则，则升级处理。

这 7 项准则改编自 William Woodruff 的 "漏洞分诊准则" （2026 年）。

适用场景

• 在人工审核前，筛选 Agent 漏洞发现流水线的结果——这是主要用途；大多数自动化运行产生的发现都无法通过一项或多项准则，可在不占用审计人员时间的情况下驳回
• 在 ToB 审计期间分诊发现结果，以决定哪些值得升级为 PoC 开发
• 对照正在审计的代码库评估第三方 CVE 或公告，以决定其是否影响项目范围
• 审查 ToB 开源项目的漏洞赏金提交或外部漏洞报告
• 在建议客户端驳回或降低已报告 CVE 的优先级时，提供有条理且站得住脚的理由

不适用场景

• 在审计期间寻找新漏洞——请使用其他技能
• 证明已确认发现的可利用性——请使用专门的 PoC／可利用性技能
• 分诊 C/C++ 中的模糊测试器崩溃——请使用专门的崩溃分诊技能

流水线位置

此技能是自动化发现与人工审核之间的质量关卡。通过分诊的发现结果将进入 PoC 开发和正式报告撰写阶段。

flowchart TD
    A([agentic vulnerability discovery]) -->|raw findings| B[vulnerability-triage-brocards]
    B -->|DISMISS| C([Document brocard # and reasoning])
    B -->|NEEDS-MORE-INFO| D([Request specific evidence])
    B -->|ACCEPT| E[PoC / exploitability proof]
    E --> F[vulnerability report writeup]

分诊工作流

对于收到的每份漏洞报告，按顺序依据全部 7 项准则进行评估。默认情况下，遇到第一个“驳回”结论时即停止并报告。如果用户要求完整评估，则不论中间环节是否未通过，都继续检查全部 7 项准则。对于每项准则，记录以下三种结论之一：

• 通过——报告通过此项测试
• 驳回——报告未通过此项测试；记录原因
• 需要更多信息——证据不足，无法评估；说明缺少哪些信息

准则 1：没有威胁模型，就没有漏洞

驳回任何缺少连贯威胁模型的报告。报告必须说明：(a) 攻击者是谁，(b) 攻击者具备什么能力，(c) 攻击者如何利用该行为，以及 (d) 会造成什么危害。

若报告描述了某种代码行为，却未将其与攻击者可触达的危害联系起来，则未通过此项准则。

**快速测试：**报告能否回答“具备［能力］的攻击者可以执行［操作］，以实现［影响］”？如果不能，则驳回或请求澄清。

准则 2：漏洞不能凭空产生

如果触发漏洞所需的攻击者能力等于或超过漏洞本身造成的影响，则驳回该报告。如果攻击者必须已经拥有该漏洞所能赋予的权限，那么这个漏洞就是多余的。

**快速测试：**触发漏洞是否需要攻击者具备已涵盖其影响的能力？如果是，则驳回。

准则 3：脱离实际使用的行为不构成漏洞

驳回任何描述理论上可能发生、但在实际软件使用中并不会发生的行为的报告。检查存在漏洞的代码路径在实践中是否可达。

**快速测试：**是否有真实调用方执行存在漏洞的代码路径？如果没有，则驳回。如果报告针对某个库，请询问是否需要检查下游使用情况。

Brocard 4：标准行为不会造成漏洞

如果某行为源于对规范的正确实现，则驳回相关报告。漏洞（如果存在）在于标准，而非实现。

注意： 如果实现自愿采取了比标准要求更严格的做法，而这种严格做法失效，则该实现存在漏洞，即使标准允许这种行为。

快速检查： 规范是否要求或允许这种行为？如果是，报告针对的是标准，而非代码。

Brocard 5：已记录的行为不会造成漏洞

如果报告描述的行为已有明确文档记录，则予以驳回，尤其是在文档说明了安全影响或使用注意事项时。

注意： 下游使用方违反已记录的指南，可能构成下游项目的有效漏洞，而非已记录该行为的组件的漏洞。

快速检查： 项目的文档是否描述了这种行为并警告不要误用？如果是，则驳回针对项目本身的报告。

Brocard 6：不能治病反而伤身

如果某报告所提的修复造成的危害大于漏洞本身，则予以驳回。评估：(a) 漏洞在实际环境中的严重程度，(b) 建议修复的成本和影响，(c) 修复措施的影响范围（依赖关系图、生态系统影响）。

快速检查： 修复此问题造成的影响是否大于漏洞本身？如果是，则驳回报告或降低严重程度。

Brocard 7：报告既非必要条件，也非充分条件

CVE 标识符或正式报告并不能证明漏洞确实存在。反过来，没有报告也不能证明安全。应独立评估技术实质，不受报告元数据影响。

快速检查： 去掉 CVE 编号和 CVSS 评分后，单凭技术描述是否足以采取行动？依据证据判断，而非权威性。

输出格式

评估完全部 7 条 Brocard 后，生成结构化的分诊摘要：

## Triage Summary: [Report ID or Title]

| # | Brocard | Verdict | Rationale |
|---|---------|---------|-----------|
| 1 | Threat Model | PASS/DISMISS/NEEDS-MORE-INFO | ... |
| 2 | Exploit from the Heavens | PASS/DISMISS/NEEDS-MORE-INFO | ... |
| 3 | Outside of Usage | PASS/DISMISS/NEEDS-MORE-INFO | ... |
| 4 | Standard Behavior | PASS/DISMISS/NEEDS-MORE-INFO | ... |
| 5 | Documented Behavior | PASS/DISMISS/NEEDS-MORE-INFO | ... |
| 6 | Cure Worse Than Disease | PASS/DISMISS/NEEDS-MORE-INFO | ... |
| 7 | Report Sufficiency | PASS/DISMISS/NEEDS-MORE-INFO | ... |

**Overall Verdict:** ACCEPT / DISMISS / NEEDS-MORE-INFO
**Reasoning:** [1-3 sentence justification]
**Next Step:** [escalate to PoC development / request info / close]

应驳回的错误判断

防范以下两个方向上的推理错误：

错误驳回有效发现

• “这只有在调试模式下才可触发”——确认生产环境中确实从未启用调试模式；许多客户端发布时会打开调试标志
• “攻击者需要本地访问权限”——对于许多部署而言，本地访问是现实的威胁模型，尤其是容器化服务
• “没人会用这个 API”——用实际使用数据确认，而非依赖假设；检查客户端的集成测试和部署配置
• “规范允许这样做”——检查实现是否声称采取了比规范要求更严格的行为

错误接受无效发现

• “它有 CVE，所以肯定是真的”——Brocard 7 的存在正是为此
• “CVSS 评分很高”——CVSS 是一种计算公式，不是裁决
• “谨慎总没错”——Brocard 6 要求评估修复成本
• “我们无法证明它不可利用”——举证责任在报告者，必须证明存在威胁模型（Brocard 1）
• “其他项目都修复了”——其他项目的使用模式可能不同（Brocard 3）
• “我们应该把它列进去，让报告内容更充实”——ToB 报告反映的是技术实情，而非发现数量目标；附有明确理由的驳回报告，比最终交付物中的误报更有价值

详细参考资料

有关每条 brocard 的详细说明、示例和边界情况，请参阅 references/brocards-detail.md。