Vulnerability Triage Brocards

Trail of BitsOfficialPublished by Trail of Bits

Skill
Review and audit
Security
CC-BY-SA-4.0
No issues found

From the author

This skill should be used when the user asks to "triage a vulnerability report", "assess a CVE", "evaluate a bug bounty submission", "decide if a finding is valid", "review a security finding", "dismiss a vulnerability", "should we fix this CVE", "prioritize a vulnerability report", or needs to determine whether an incoming vulnerability report warrants investigation. Applies 7 brocards (rules of thumb) to systematically accept, dismiss, or request more information on vulnerability reports, or needs to filter raw findings from agentic vulnerability discovery pipelines before human review.

— the description by Trail of Bits

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

Vulnerability-triage-brocards provides a structured, defensible methodology for evaluating security findings. Based on seven specific criteria, this skill helps security professionals and automated pipelines filter out noise, identify valid vulnerabilities, and determine when more information is required. By applying these rules, users can avoid common pitfalls like over-relying on CVE metadata or failing to account for real-world usage, ensuring that human review time is focused on genuine, actionable security risks.

What it does

Applies seven distinct criteria to evaluate the validity of vulnerability reports.
Provides a structured output format including a triage summary table and final verdict.
Helps filter raw findings from automated vulnerability discovery pipelines.
Guides users in deciding whether to accept, dismiss, or request more information for a finding.
Offers a defensible rationale for dismissing or deprioritizing security reports.
Distinguishes between theoretical bugs and actionable security vulnerabilities.

When to use it

When filtering large volumes of findings from automated security discovery tools.
When triaging bug bounty submissions or external security reports.
When deciding whether a third-party CVE or advisory is relevant to a specific codebase.
When needing a structured, consistent approach to justify dismissing a vulnerability to a client.
During security audits to prioritize findings for proof-of-concept development.

Advantages

Reduces auditor fatigue by filtering out invalid or non-actionable findings.
Provides a consistent, repeatable framework for security decision-making.
Encourages evidence-based evaluation rather than relying on external metadata like CVSS scores.
Helps identify when a report describes a bug rather than a security vulnerability.
Ensures that remediation efforts are balanced against the actual risk and cost.

Usage examples

“Triage this vulnerability report: [Insert Report Details]. Apply the 7 brocards.”: The agent will evaluate the report against each of the 7 criteria, providing a table of verdicts (PASS/DISMISS/NEEDS-MORE-INFO) and a final recommendation on whether to proceed.
“Should we fix this CVE? Evaluate it using the brocards.”: The agent will analyze the CVE's technical merits, check for reachability and threat model validity, and provide a recommendation based on whether the fix is necessary and proportional.

Install

Download the skill as a ZIP:
https://autogineer.com/agent-skills/trailofbits/vulnerability-triage-brocards/download

Unzip it into the cross-client skills folder of your project:

mkdir -p .agents/skills && unzip vulnerability-triage-brocards.zip -d .agents/skills

Documentation by Trail of Bits

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.

Brocard 5: No Vulnerability from Documented Behavior

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

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.

Brocard 7: The Report Is Neither Necessary nor Sufficient

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.

Output Format

After evaluating all 7 brocards, produce a structured triage summary:

## 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]

Rationalizations 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

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

Detailed References

For expanded explanations, examples, and edge cases for each brocard, consult references/brocards-detail.md.

Files

ATTRIBUTION.mdAdded by AutoGineer981 B
LICENSELicence file added by AutoGineer19.7 KiB
SKILL.md8.5 KiB
references/brocards-detail.md10.5 KiB

references/brocards-detail.md

Brocards for Vulnerability Triage -- Detailed Reference

Expanded explanations, concrete examples, and edge cases for each of the 7 brocards. Consult this file when a brocard evaluation is ambiguous or when documenting a dismissal that requires detailed justification.

Source: William Woodruff, "Brocards for vulnerability triage" (2026).

Brocard 1: No Vulnerability Without a Threat Model

Principle

A vulnerability report that does not articulate a coherent threat model -- who the attacker is, what capability they have, how they exploit the behavior, and what harm results -- can be dismissed. The burden of proof falls on the reporter to connect code behavior to real-world harm.

Examples

Scenario	Verdict	Reasoning
Python API raises exceptions in undocumented edge cases	DISMISS	No exploitation mechanism described; an exception is not inherently harmful without a path from attacker input to that exception causing damage
Hang in a local developer tool	DISMISS	The developer can simply kill the process; no remote attacker, no persistent harm
Heap overflow in a network-facing parser	PASS	Attacker sends crafted input over the network, triggers overflow, achieves code execution

Edge Cases

A report may describe a real code defect without it being a vulnerability. Bugs and vulnerabilities are not synonyms. A missing threat model may indicate the report describes a bug, not a security issue.
If the reporter provides a partial threat model, request the missing pieces rather than dismissing outright. Issue a NEEDS-MORE-INFO verdict specifying which elements (attacker, capability, exploit mechanism, or impact) are absent.

Brocard 2: No Exploit from the Heavens

Principle

Reject reports where the attacker capabilities required to trigger the vulnerability equal or exceed the vulnerability's impact. The vulnerability is redundant -- the attacker already possesses the power the exploit would grant.

Examples

Scenario	Verdict	Reasoning
Content manipulation on a web service, but only with active MITM	DISMISS	An active MITM attacker can already inject arbitrary content; the vulnerability adds nothing to their capability
Code execution via ctypes manipulation of CPython object internals	DISMISS	Using ctypes to corrupt memory already requires arbitrary code execution in the Python process
SSRF via user-controlled URL parameter	PASS	The attacker controls a URL string (low capability) but gains internal network access (high impact) -- capability less than impact

Edge Cases

Privilege escalation chains may appear to violate this brocard but do not: an attacker with limited access exploiting a vulnerability to gain elevated access is valid because the post-exploit capability exceeds the pre-exploit capability.
Carefully distinguish between "the attacker can do X" and "the attacker can do X in this context." Local code execution in a sandboxed environment is not the same as local code execution with full privileges.

Brocard 3: No Vulnerability Outside of Usage

Principle

Behavior that could occur but does not in actual software usage is not a vulnerability. The vulnerable code path must be reachable in practice.

Examples

Scenario	Verdict	Reasoning
Private API with buffer overflow, but the only caller passes a fixed-size buffer	DISMISS	The vulnerable path is never exercised with attacker-controlled data
C function with overflow risk, but all call sites statically verified as safe	DISMISS	No real-world caller triggers the overflow
OpenSSL vulnerability in a function CPython never calls	DISMISS	Upstream vulnerability is not reachable through the downstream API surface
Public API with documented precondition (valid UTF-8), all callers maintain invariant	DISMISS	The invariant holds across all usage; the theoretical violation does not occur
Library function with overflow, used by 200+ downstream packages (not all audited)	PASS	Cannot verify all callers maintain safe usage; at least some may be vulnerable

Edge Cases

For libraries with broad downstream usage, "outside of usage" requires checking representative downstream callers, not just the library's own test suite.
Future usage changes may introduce reachability. If the code is a public API with no usage restrictions, consider whether dismissal should include a recommendation to add API guards or documentation (linking to Brocard 5).
Unreachable code in the current version may become reachable after refactoring. If the codebase is under active development, note this caveat in the triage summary.

Brocard 4: No Vulnerability from Standard Behavior

Principle

Behavior that results from correct implementation of a specification is not a vulnerability in the implementation. The vulnerability, if any, exists in the standard itself.

Examples

Scenario	Verdict	Reasoning
HTTP server implements robustness principle per RFC 7230	DISMISS	The server correctly follows the RFC; report the concern to the standards body
HMAC-MD5 usage reported as "using broken MD5"	DISMISS	MD5 collision resistance is broken, but HMAC-MD5 does not depend on collision resistance; the construction is sound
TLS 1.2 implementation supporting CBC cipher suites	Conditional	If the implementation claims TLS 1.3-only but falls back to 1.2 CBC, the implementation's stricter claim is violated

Edge Cases

Voluntary strictness exception: When an implementation advertises stricter behavior than the standard requires (e.g., "we only support TLS 1.3"), failure to enforce that strictness is a vulnerability in the implementation, even though the standard permits the behavior. Always check whether the project makes security claims beyond the spec.
Standards themselves can be vulnerable. If a brocard-4 dismissal applies, consider whether an advisory should be filed against the standard rather than the implementation.

Brocard 5: No Vulnerability from Documented Behavior

Principle

Behavior that is explicitly documented -- especially with security implications or usage caveats -- cannot be reported as a vulnerability in the component that documents it.

Examples

Scenario	Verdict	Reasoning
Python http.server, explicitly marked "not suitable for production"	DISMISS	Documentation explicitly warns against production use
Python serialization module documented as "insecure by design"	DISMISS	The insecurity is intentional and documented
Downstream web app deserializing untrusted user input with an insecure serializer	PASS	The downstream project violates documented guidelines; the vulnerability is in the downstream project
CLI tool with --insecure flag that disables TLS verification	DISMISS	The flag is documented; the user opted in

Edge Cases

Documentation buried in obscure locations (e.g., a footnote in a changelog) provides weaker protection than prominent warnings. If the documentation is not reasonably discoverable, this brocard may not fully apply.
"Documented" does not mean "acceptable." A component that documents dangerous behavior without offering a safe alternative may warrant a report requesting a safer default, even if the current behavior is technically documented.
Downstream misuse of documented behavior is a valid finding against the downstream project. Always clarify which component the report targets.

Brocard 6: No Cure Worse Than the Disease

Principle

Reject reports whose remediation would cause more disruption than the vulnerability itself. Evaluate the vulnerability's practical severity against the fix's cost, disruption, and ecosystem blast radius.

Examples

Scenario	Verdict	Reasoning
ReDoS with negligible practical impact, but fixing it breaks thousands of downstream packages	DISMISS	Remediation disruption far exceeds the vulnerability's marginal impact
CVE-2026-4539 against pygments: unfounded medium-severity report affecting tens of thousands of deps	DISMISS	The report itself caused more harm (forced dependency updates, CI breakage) than the alleged vulnerability
Critical RCE in a widely-used library	PASS	Even if the fix is disruptive, the vulnerability's severity justifies the cost

Edge Cases

This brocard does not excuse ignoring vulnerabilities -- it requires proportional response. A low-severity issue may warrant a low- disruption fix (documentation update, deprecation notice) rather than no action.
Consider whether the "cure" can be staged: a breaking fix in a major version release is less disruptive than an emergency patch that forces immediate migration.
Ecosystem-level thinking is required. A vulnerability in a leaf dependency with 10 users has a different blast radius than the same vulnerability in a package with 100,000 dependents.

Brocard 7: The Report Is Neither Necessary nor Sufficient

Principle

Formal reports and CVE identifiers do not prove vulnerability existence. Conversely, absence of a report does not prove safety. Evaluate technical merits independently of report metadata.

Application

Strip the CVE number, CVSS score, and reporter's credentials before evaluating. Does the technical description alone justify action?
A high CVSS score with a vague description is a red flag, not a green light.
Conversely, an informally reported issue without a CVE may be critical. Do not deprioritize findings based on their reporting channel.
CVSS is a formula that produces a number; it is not a substitute for contextual analysis. Two vulnerabilities with identical CVSS scores may have wildly different real-world impact depending on deployment context.

Examples

Scenario	Verdict	Reasoning
CVE with CVSS 9.8 but description says "may cause unexpected behavior"	NEEDS-MORE-INFO	High score but vague description; demand specific technical evidence
Informal email describing a concrete exploit chain, no CVE	Evaluate on merits	Lack of formal report does not diminish technical validity
Automated scanner output assigning CVE to a dependency	Verify independently	Scanner output is neither necessary nor sufficient; check if the vulnerable code path is reachable (Brocard 3)

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Security

No issues found by our static scan· No issues found

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Published by

Trail of Bits

Publisher

Trail of Bits (Official)

Source

trailofbits/skills · plugins/vulnerability-triage-brocards/skills/vulnerability-triage-brocards · commit e4dd0bb

Licence

Creative Commons Attribution-ShareAlike 4.0 International (redistribution allowed)

LICENSE (added by AutoGineer from LICENSE)
ATTRIBUTION.md (written by AutoGineer)

Synced

2026-11-09

AutoGineer is not affiliated with or endorsed by Trail of Bits or Trail of Bits.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download vulnerability-triage-brocards.zip

From the author

AutoGineer summary

What it does

When to use it

Advantages

Usage examples

Install

Documentation by Trail of Bits

Vulnerability Triage Brocards

When to Use

When NOT to Use

Pipeline Position

Triage Workflow

Brocard 1: No Vulnerability Without a Threat Model

Brocard 2: No Exploit from the Heavens

Brocard 3: No Vulnerability Outside of Usage

Brocard 4: No Vulnerability from Standard Behavior

Brocard 5: No Vulnerability from Documented Behavior

Brocard 6: No Cure Worse Than the Disease

Brocard 7: The Report Is Neither Necessary nor Sufficient

Output Format

Rationalizations to Reject

Wrongly Dismissing Valid Findings

Wrongly Accepting Invalid Findings

Detailed References

Files

references/brocards-detail.md

Brocards for Vulnerability Triage -- Detailed Reference

Brocard 1: No Vulnerability Without a Threat Model

Principle

Examples

Edge Cases

Brocard 2: No Exploit from the Heavens

Principle

Examples

Edge Cases

Brocard 3: No Vulnerability Outside of Usage

Principle

Examples

Edge Cases

Brocard 4: No Vulnerability from Standard Behavior

Principle

Examples

Edge Cases

Brocard 5: No Vulnerability from Documented Behavior

Principle

Examples

Edge Cases

Brocard 6: No Cure Worse Than the Disease

Principle

Examples

Edge Cases

Brocard 7: The Report Is Neither Necessary nor Sufficient

Principle

Application

Examples

Requirements and compatibility

Security

Attribution and licence

Related skills

Security Audit

Sast Configuration

Firmware Analyst

Policy Enforcer

Backend Development Security Auditor

Memory Forensics

Download ZIP