/vulnerability-triage

name: vulnerability-triage
description: Reference vocabulary for interpreting vulnerability findings — detector-vs-impact distinction, severity anchoring on demonstrated evidence, the eleven-item interpretation rubric, delegation transparency, primitive-extent scaling, the disqualifier taxonomy (D-0..D-4), CVSS Achievable / Environmental framing, hedging-phrase elimination, and falsification asymmetry. Read when interpreting a finding to decide whether the demonstrated evidence supports the severity it would warrant. Surface-neutral; pulls in the relevant surface skill (e.g. `memory-safety-c-cpp`) for bug-class-specific exploitability factors.

Vulnerability Triage

Reference vocabulary for interpreting what an investigation actually demonstrated and translating it into threat-model language. Catalogs the rubric, disqualifiers, scoring conventions, and pitfalls a triage decision needs to reason about.

Core rule

Severity is anchored on what was actually demonstrated, never on the theoretical maximum implied by the vulnerable code. A detector firing on an isolated harness — sanitizer, fuzz crash, static analyzer hit, tainted-flow report, schema-validator alert, assertion failure — proves the detector caught something. It does NOT prove attacker-visible impact. Confidentiality, integrity, and availability claims require the corresponding effect to have been observed in production-equivalent conditions. When the demonstrated observation is weaker than the theoretical ceiling, score the demonstrated level and label the ceiling as such.

Detector evidence vs impact evidence

These two are routinely confused. Hold the line between them.

**Detector evidence** is anything a tool flagged: ASAN / UBSAN / TSAN / MSan crash, libFuzzer reproducer, static-analyzer warning, taint-flow trace, assertion site, schema-validator alert, AST pattern match. Detector evidence proves the detector caught an anomaly at the named site. It says nothing on its own about whether an attacker can reach that site, supply attacker-useful values, or observe the result.

**Impact evidence** is an observation of an attacker-visible CIA effect under production-equivalent conditions: reading bytes the attacker did not previously hold, mutating state the attacker did not previously control, denying service to a user other than the attacker, gaining a capability the attacker did not previously have. Impact evidence is anchored on observable artifacts — a crash, sanitizer trace, changed output, callback fired, file read, error message, measurable state change.

"Ran without error" is not impact evidence. If the expected effect was not observed, either the experiment was wrong or the bug is not triggered — diagnose which; do not paper over. A finding supported only by detector evidence is a detector hit awaiting demonstration, not a confirmed vulnerability.

Interpretation rubric

For each finding, the rubric below has eleven items. Skipping any one of them is a triage failure. Each item names a question, what counts as a complete answer, and what an incomplete answer looks like.

1. **Reproduction.** Re-run the exact input. Confirm the same observation. Complete answer: same input, same observation, same artifact (crash signature, sanitizer trace, observed output). Incomplete: "should reproduce", "did not retry", or a different observation than the original. If reproduction fails, the finding is not yet triageable.

2. **Effect realism.** Classify the observation against the four categories below; the first two support an impact claim, the last two refute it.

• Attacker-uncontrolled target state observed (genuine impact).
• Attacker-controlled effect on state the attacker did not previously hold (genuine impact).
• Attacker's own input echoed or round-tripped back, or constant / neutral state (zeroed memory, schema-sanitized placeholder, default config, empty collection) — no impact.
• Non-exploitable error path the attacker cannot steer — no impact.

Reject impact claims when the observation falls in the last two categories.

3. **Attacker control surface.** Is the effect's extent adversary-chosen, or bounded by structure the attacker cannot influence? Complete answer: explicitly state which input fields drive the effect's size, location, or content, and which are fixed by the surrounding code. Incomplete: "the attacker controls the input" without naming which subset of the input controls which dimension of the effect.

4. **Adjacency / payload model.** What attacker-useful content plausibly reaches the affected location in production state? For memory-read findings, what target state sits adjacent to the affected region. For injection findings, what sink does the tainted value reach. For auth-bypass findings, what resources become reachable. State this as a reasoned model unless the experiment measured the specific payload.

5. **Channel reality.** In deployed configurations, does the attacker actually observe the effect? Some channels realize impact (metadata APIs, attacker-rendered output, error messages echoed back). Others absorb or drop it (batch jobs, log-only sinks, sandboxed processes, observation channels not exposed to the caller). Complete answer: name the production channel through which the effect would be observed; trace it from the bug site to where the attacker sees it.

6. **Production hardening.** What mitigations present in production (sanitizers, schema validators, CSP, ASLR, stack canaries, auth middleware, sandbox, rate limits, RELRO, FORTIFY_SOURCE) change the attacker's success rate? Did the experiment use the production profile or bypass it? A harness with hardening stripped tells you nothing about production outcomes — score what production does, not what the harness did.

When a mitigation table asserts a runtime cap, flag, or mode is at a particular default value in production, cite the line that *registers* that default (GObject property spec, struct initialize