/finding-triage

name: finding-triage
description: "Triage a single security finding — from a scanner, audit, advisory, or report — to a defensible disposition with a mitigation plan, false-positive justification, or accepted-risk writeup. Use when the user mentions 'triage this finding,' 'is this a real vulnerability,' 'mitigation plan,' 'false positive,' 'accept this risk,' 'compensating controls,' 'risk justification,' 'security ticket,' 'CVSS this,' 'should we fix this,' 'disposition,' 'sign off on,' or has a single security finding and needs to decide what to do."
allowed-tools: Read, Grep, Glob, Bash, WebSearch

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 flags the same thing, the prior false-positive note saves them the work.

Step 3 — Contextual severity

The scanner's CVSS or severity rating is a starting point, not the answer. Adjust for your context.

**Factors that increase severity beyond the rating:**

• Vulnerable endpoint is internet-facing, not internal
• Authentication preconditions are easy to satisfy (open signup) in your app, even if the CVE assumes "authenticated"
• Vulnerable data is regulated (PII, PCI cardholder data, PHI) — exploitation has reportable-incident consequences
• Public PoC exists or active exploitation observed
• Vulnerable component is in the critical path (every request touches it)
• Compensating controls are missing or weak

**Factors that decrease severity below the rating:**

• Vulnerable code path is unreachable in your usage (read the patch, grep for the function — see `vuln-research`)
• Strong compensating controls (WAF blocks the payload pattern, network segmentation prevents reach)
• Exploit requires preconditions that don't exist in your environment (specific OS version, specific config)
• Authentication preconditions are hard in your app (closed signup, MFA, employee-only)
• Component is dev-only or build-only, not runtime-reachable

**Severity scale (use the one your org uses; here's a common one):**

| Level | Definition | |---|---| | **Critical** | Pre-auth or trivially exploitable; immediate data loss / RCE / takeover; patch within 24-72 hours | | **High** | Auth required but minimal privilege; or post-auth path to significant impact; patch within 1-2 weeks | | **Medium** | Requires meaningful privilege or chain; realistic but not trivial; patch within 30 days | | **Low** | Defense-in-depth; hard to chain; patch within 90 days | | **Info** | Hardening or hygiene; documented behavior; patch when convenient |

Step 4 — Pick the disposition

| Disposition | When to choose | Required fields | |---|---|---| | **Fix now** (synonym: **Fixed**) | Patch / mitigation deployab