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:

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):