# vulnerability-triage-brocards

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.

- **Kind:** skill
- **Source:** https://github.com/trailofbits/skills
- **Page:** https://forefy.com/skills/f9084b1f-e2ac-4e9a-8c4e-8acd53342ce5
- **API (JSON + files):** https://forefy.com/api/asr/f9084b1f-e2ac-4e9a-8c4e-8acd53342ce5

---

## SKILL.md

---
name: vulnerability-triage-brocards
description: >-
  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.
---

# 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"](https://vulnbrocards.com/)
(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.

```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

### 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`](references/brocards-detail.md).

## references

```

```

## 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](https://nvd.nist.gov/vuln/detail/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) |