vulnerability-triage-brocards
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseVulnerability Triage Brocards
漏洞分类准则
Systematically evaluate incoming vulnerability reports against 7 principled
criteria before committing resources to deeper analysis. Each brocard is a
falsifiable test: if a report fails any brocard, document the reason and
dismiss or request clarification. If a report survives all 7, escalate it.
The 7 brocards are adapted from William Woodruff's
"Brocards for vulnerability triage"
(2026).
在投入资源进行深度分析前，系统地根据7条原则标准评估收到的漏洞报告。每条准则都是可证伪的测试：如果报告未通过任意一条准则，记录原因并驳回或请求澄清。如果报告通过全部7条准则，则将其升级处理。
这7条准则改编自William Woodruff在2026年发布的《漏洞分类准则》。
When to Use
适用场景
- Filtering findings from agentic vulnerability discovery pipelines before human review -- the primary use case; most automated runs produce findings that fail one or more brocards and can be dismissed without auditor time
- Triaging findings during a ToB audit to decide which warrant escalation to PoC development
- Evaluating third-party CVEs or advisories against a codebase under active audit to decide if they affect engagement scope
- Reviewing bug bounty submissions or external vulnerability reports for ToB open-source projects
- Providing structured, defensible justification when recommending a client dismiss or deprioritize a reported CVE
- 在人工审核前过滤来自智能漏洞发现管道的结果——这是主要使用场景；大多数自动化扫描产生的结果会未通过一条或多条准则，无需审核人员介入即可驳回
- 在ToB审计期间对发现结果进行分类，决定哪些值得升级到PoC开发阶段
- 针对正在审计的代码库评估第三方CVE或公告，判断它们是否影响审计范围
- 审核ToB开源项目的漏洞赏金提交内容或外部漏洞报告
- 当建议客户驳回或降低已报告CVE的优先级时，提供结构化、可辩护的理由
When NOT to Use
不适用场景
- Hunting for new bugs during an audit -- use other skills
- Proving exploitability of a confirmed finding -- use a dedicated PoC/exploitability skill
- Triaging fuzzer crashes in C/C++ -- use a dedicated crash triage skill
- 审计期间寻找新漏洞——使用其他Skill
- 证明已确认发现结果的可利用性——使用专门的PoC/可利用性Skill
- 分类C/C++模糊测试器崩溃结果——使用专门的崩溃分类Skill
Pipeline Position
管道定位
This skill is the quality gate between automated discovery and human
review. Findings that survive triage proceed to PoC development and
formal writeup.
mermaid
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]本Skill是自动化发现与人工审核之间的质量关卡。通过分类的结果将进入PoC开发和正式报告撰写阶段。
mermaid
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]Triage Workflow
分类工作流
For each incoming vulnerability report, evaluate it against all 7 brocards
sequentially. By default, stop at the first DISMISS verdict and report it.
If the user requests a full evaluation, continue through all 7 brocards
regardless of intermediate failures. For each brocard, record one of three
verdicts:
- PASS -- the report survives this test
- DISMISS -- the report fails this test; document the reason
- NEEDS-MORE-INFO -- insufficient evidence to evaluate; specify what is missing
对于每一份收到的漏洞报告，依次根据全部7条准则进行评估。默认情况下，一旦出现第一个DISMISS结论就停止评估并上报。如果用户要求全面评估，则无论中间是否失败，都要完成全部7条准则的评估。针对每条准则，记录以下三种结论之一：
- PASS——报告通过该测试
- DISMISS——报告未通过该测试；记录原因
- NEEDS-MORE-INFO——证据不足无法评估；说明缺失的内容
Brocard 1: No Vulnerability Without a Threat Model
准则1：无威胁模型则无漏洞
Dismiss any report that lacks a coherent threat model. The report must
articulate: (a) who the attacker is, (b) what capability the attacker has,
(c) how the attacker exploits the behavior, and (d) what harm results.
Reports that describe a code behavior without connecting it to attacker-
reachable harm fail this brocard.
Quick test: Can the report answer "an attacker with [capability] can
[action] to achieve [impact]"? If not, dismiss or request clarification.
驳回任何缺乏连贯威胁模型的报告。报告必须明确说明：(a)攻击者是谁，(b)攻击者具备何种能力，(c)攻击者如何利用该行为，(d)会造成何种危害。
仅描述代码行为但未将其与攻击者可达成的危害关联的报告，未通过本准则。
快速测试： 报告能否回答「具备[能力]的攻击者可以[操作]以实现[影响]」？如果不能，驳回或请求澄清。
Brocard 2: No Exploit from the Heavens
准则2：无空中楼阁式漏洞利用
Dismiss any report where the attacker capabilities required to trigger the
vulnerability equal or exceed the impact of the vulnerability itself. If the
attacker must already possess the power the exploit would grant, the
vulnerability is redundant.
Quick test: Does triggering the exploit require capabilities that already
subsume its impact? If yes, dismiss.
驳回任何触发漏洞所需的攻击者能力等于或超过漏洞本身影响的报告。如果攻击者必须已经拥有漏洞利用将赋予的权限，那么该漏洞是冗余的。
快速测试： 触发漏洞利用是否需要已经涵盖其影响的能力？如果是，驳回。
Brocard 3: No Vulnerability Outside of Usage
准则3：无脱离实际使用的漏洞
Dismiss any report describing behavior that is theoretically possible but
does not occur in actual software usage. Check whether the vulnerable code
path is reachable in practice.
Quick test: Is the vulnerable code path exercised by any real caller?
If not, dismiss. If the report targets a library, ask if we should check
downstream usage.
驳回任何描述理论上可行但实际软件使用中不会发生的行为的报告。检查易受攻击的代码路径在实际中是否可达。
快速测试： 易受攻击的代码路径是否有真实调用者触发？如果没有，驳回。如果报告针对的是库，询问是否需要检查下游使用情况。
Brocard 4: No Vulnerability from Standard Behavior
准则4：无标准行为导致的漏洞
Dismiss any report where the behavior results from correct implementation of
a specification. The vulnerability, if any, exists in the standard -- not the
implementation.
Nuance: If an implementation voluntarily adopts a stricter posture than
the standard requires, and that strictness fails, the implementation is
vulnerable even though the standard permits the behavior.
Quick test: Does the specification require or permit this behavior? If
yes, the report targets the standard, not the code.
驳回任何行为源于规范正确实现的报告。如果存在漏洞，问题出在规范本身——而非实现。
细节说明： 如果实现主动采用了比规范要求更严格的机制，且该机制失效，那么即使规范允许该行为，该实现仍存在漏洞。
快速测试： 规范是否要求或允许该行为？如果是，报告针对的是规范而非代码。
Brocard 5: No Vulnerability from Documented Behavior
准则5：无文档化行为导致的漏洞
Dismiss any report describing behavior that is explicitly documented,
especially when the documentation includes security implications or usage
caveats.
Nuance: Downstream usage that violates documented guidelines may
constitute a valid vulnerability in the downstream project, not the
documented component.
Quick test: Does the project's documentation describe this behavior and
warn against misuse? If yes, dismiss the report against the project itself.
驳回任何描述已明确文档化行为的报告，尤其是文档中包含安全影响或使用注意事项的情况。
细节说明： 下游使用违反文档指南的情况，可能构成下游项目中的有效漏洞，但不涉及被文档化的组件。
快速测试： 项目文档是否描述了该行为并警告误用？如果是，驳回针对该项目本身的报告。
Brocard 6: No Cure Worse Than the Disease
准则6：无弊大于利的修复
Dismiss any report whose remediation would cause more harm than the
vulnerability itself. Evaluate: (a) severity of the vulnerability in
practice, (b) cost and disruption of the proposed fix, (c) blast radius of
the remediation (dependency graph, ecosystem impact).
Quick test: Would fixing this cause more disruption than the
vulnerability itself? If yes, dismiss or downgrade severity.
驳回任何修复方案造成的危害超过漏洞本身的报告。评估：(a)漏洞实际的严重程度，(b)提议修复的成本和破坏性，(c)修复的影响范围（依赖图、生态系统影响）。
快速测试： 修复该漏洞是否会比漏洞本身造成更大的破坏？如果是，驳回或降低严重程度。
Brocard 7: The Report Is Neither Necessary nor Sufficient
准则7：报告既非必要也非充分
A CVE identifier or formal report does not prove a vulnerability exists.
Conversely, absence of a report does not prove safety. Evaluate the
technical merits independently of report metadata.
Quick test: Strip the CVE number and CVSS score. Does the technical
description alone justify action? Judge on evidence, not authority.
CVE标识符或正式报告不能证明漏洞存在。反之，没有报告也不能证明安全。应独立于报告元数据评估技术价值。
快速测试： 去掉CVE编号和CVSS评分。仅技术描述本身是否值得采取行动？基于证据判断，而非权威。
Output Format
输出格式
After evaluating all 7 brocards, produce a structured triage summary:
undefined完成全部7条准则评估后，生成结构化的分类摘要：
undefinedTriage Summary: [Report ID or Title]
分类摘要：[报告ID或标题]
| # | 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]
undefined| # | 准则 | 结论 | 理由 |
|---|---|---|---|
| 1 | 威胁模型 | PASS/DISMISS/NEEDS-MORE-INFO | ... |
| 2 | 空中楼阁式漏洞利用 | PASS/DISMISS/NEEDS-MORE-INFO | ... |
| 3 | 脱离实际使用 | PASS/DISMISS/NEEDS-MORE-INFO | ... |
| 4 | 标准行为 | PASS/DISMISS/NEEDS-MORE-INFO | ... |
| 5 | 文档化行为 | PASS/DISMISS/NEEDS-MORE-INFO | ... |
| 6 | 弊大于利的修复 | PASS/DISMISS/NEEDS-MORE-INFO | ... |
| 7 | 报告充分性 | PASS/DISMISS/NEEDS-MORE-INFO | ... |
整体结论： ACCEPT / DISMISS / NEEDS-MORE-INFO
理由： [1-3句话说明]
下一步： [升级到PoC开发 / 请求信息 / 关闭]
undefinedRationalizations to Reject
需避免的错误推理
Guard against these reasoning failures in both directions:
防范双向的推理失误：
Wrongly Dismissing Valid Findings
错误驳回有效发现
- "It's only reachable in debug mode" -- verify debug mode is truly never enabled in production; many clients ship with debug flags on
- "The attacker would need local access" -- local access is a realistic threat model for many deployments, especially containerized services
- "Nobody uses that API" -- confirm with actual usage data, not assumptions; check client's integration tests and deployment configs
- "The spec allows it" -- check whether the implementation claims stricter behavior than the spec requires
- 「仅在调试模式下可达」——验证调试模式是否真的从未在生产环境启用；许多客户会开启调试标志发布
- 「攻击者需要本地访问权限」——本地访问对于许多部署来说是现实的威胁模型，尤其是容器化服务
- 「没人使用那个API」——用实际使用数据确认，而非假设；检查客户的集成测试和部署配置
- 「规范允许该行为」——检查实现是否声称比规范要求更严格的行为
Wrongly Accepting Invalid Findings
错误接受无效发现
- "It has a CVE, so it must be real" -- Brocard 7 exists for this reason
- "The CVSS score is high" -- CVSS is a formula, not a verdict
- "Better safe than sorry" -- Brocard 6 requires evaluating fix cost
- "We can't prove it's NOT exploitable" -- the burden of proof is on the reporter to demonstrate a threat model (Brocard 1)
- "Other projects patched it" -- other projects may have different usage patterns (Brocard 3)
- "We should include it to pad the report" -- ToB reports reflect technical reality, not finding count targets; a dismissed report with documented reasoning is more valuable than a false positive in a final deliverable
- 「它有CVE，所以肯定是真实的」——准则7就是为此设立的
- 「CVSS分数很高」——CVSS是公式，而非结论
- 「宁可信其有」——准则6要求评估修复成本
- 「我们无法证明它不可利用」——举证责任在报告方，需展示威胁模型（准则1）
- 「其他项目已修复」——其他项目可能有不同的使用模式（准则3）
- 「我们应该把它加进去凑报告数量」——ToB报告反映技术事实，而非发现数量指标；带有记录理由的驳回报告比最终交付物中的误报更有价值
Detailed References
详细参考资料
For expanded explanations, examples, and edge cases for each brocard, consult
.
references/brocards-detail.md如需每条准则的扩展解释、示例和边缘案例，请查阅。
references/brocards-detail.md