Vulnerability Triage Brocards

Vulnerability 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).

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

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

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.

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

Brocard 1: No Vulnerability Without a Threat Model

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.

Brocard 2: No Exploit from the Heavens

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

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

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.