Finding Triage

# Finding Triage — Single-Finding Disposition with Defensible Justification

Every other skill in this repo *generates* findings. This skill *closes the loop* — for a single finding, walk through whether it's real, what severity it deserves in your context, and what to do about it. Output is a complete ticket-ready writeup with the right fields, the right justification, and an audit trail that survives a regulator reading it six months later.

The dispositions match `owasp-audit`'s Three-Disposition rule: **Fixed**, **Deferred**, or **Accepted Risk**. False positive is a fourth — but it isn't a disposition for a real finding, it's a determination that there *is* no finding.

This skill works on findings from any source: SAST output, DAST scanner, dependency advisory, manual audit, threat-hunt hit, pentest report, vendor disclosure, internal red-team writeup, bug bounty submission.

Cross-references:
- `vuln-research` for the technical CVE deep-dive that feeds reachability assessment here
- `owasp-audit` Three-Disposition rule (the framework this implements per-finding)
- `security-comms` for translating the disposition writeup into stakeholder-readable language when the finding has to leave the security context
- Any audit skill — this consumes their findings as input

## Workflow

The agent works through these steps with the user. Stop and ask clarifying questions where the user has context the finding alone doesn't reveal.

### Step 1 — Restate the finding in your own words

If the finding came from a scanner, restate what's actually being claimed. Scanners produce noise; restating filters out the boilerplate.

A good restatement names:
- **What** the issue is (specific weakness — CWE if applicable)
- **Where** it lives (file:line, endpoint, resource ARN, host)
- **How** it could be exploited (preconditions, attacker capability needed)
- **Impact** if it were exploited (data loss, privilege escalation, availability)

If you can't restate it clearly, you don't understand it yet. Ask the user for context.

### Step 2 — Is this actually true?

Half of automated-scanner findings are false positives by volume. The triage:

| Question | If yes | If no |
|---|---|---|
| Does the vulnerable code path exist as described? | Continue | False positive — scanner found a phantom |
| Is the code path reachable from any attacker-controllable input? | Continue | Continue, but severity drops |
| Does the exploit precondition match your environment? | Continue | Severity drops or false positive |
| Is there a public PoC, or has anyone confirmed this in the wild? | Severity stays / rises | Severity may drop |
| Are existing controls (WAF, auth, network segmentation) preventing exploitation? | Severity drops; controls become the mitigation | Severity stays |

**Common false-positive patterns:**
- SAST flag on test files or dead code
- Dependency scanner flag on package in `devDependencies` only — runtime-unreachable (see `dependency-audit` reachability column)
- DAST flag on a path that returns 404 in your real environment but was confused by SPA routing
- Outdated advisory — vendor silently fixed it before the CVE; your version contains the fix
- Pattern match on code that *looks* vulnerable but is inside a function never invoked

**Document a false-positive determination as carefully as a real finding.** If a future scanner or auditor fla