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 deployable within the severity's SLA	Fix description, deploy plan, verification method
Defer	Severity warrants action, but operational constraints make immediate fix infeasible	Reason for deferral, new deadline, who owns, alerting if conditions change before deadline
Accept risk	Fix isn't planned at current configuration	(1) Why fix doesn't apply, (2) Compensating controls, (3) Re-evaluation trigger
False positive	Not actually a vulnerability	Evidence for the determination, scanner rule ID to suppress (with care)

On Defer: severity does NOT change because you decided to defer. Recording a "High deferred to Q3" is honest; downgrading a High to Medium because Q3 is far away is risk-laundering.

On Accept Risk: all three fields are required. An "Accepted Risk" without all three is a real finding being silently dropped. The re-evaluation trigger is the most-skipped field — name a specific condition (plan upgrade, dependency bump, traffic pattern change, audit anniversary).

Step 5 — Write the disposition

Produce a ticket-ready writeup. Use one of these templates depending on disposition.

Template: Fix

## Finding: [Title]
**Source:** [scanner / audit / advisory]
**Severity:** [contextual] (Scanner reported: [original])
**CWE / CVE:** [if applicable]
**Location:** [file:line / endpoint / resource]

### What
[Plain-English description — what the issue is]

### Why this severity
[Contextual reasoning — what the scanner missed, what your environment adds]

### Fix
[Specific change — code diff, config update, dependency upgrade]

### Verification
[Concrete test — adversarial input + observed result that proves the fix holds]
- Run [command / test case]
- Observe [response / behavior]

### Owner: [name]
### Target deploy: [date]

Template: Defer

## Finding: [Title] — DEFERRED
**Severity:** [unchanged]
**Original target:** [original SLA date]
**New target:** [date]

### Why deferred
[Operational constraint — release freeze, dependency on third party, etc.]

### Risk during deferral window
[What's the exposure? What controls reduce it?]

### Alerting / conditions that would escalate
[What would force action sooner than the new target?]

### Owner: [name]
### Re-evaluation: [date — usually before new target]

Template: Accept Risk

## Finding: [Title] — ACCEPTED RISK
**Severity:** [contextual]
**Approver:** [name + role]
**Date accepted:** [date]

### Why fix doesn't apply
[Cost tier, dependency version constraint, deployment topology, vendor limitation, etc. — be specific]

### Compensating controls
- [Control 1 — what it is, why it reduces impact / likelihood]
- [Control 2]
- ...

### Re-evaluation trigger
[Specific condition — plan upgrade, dependency bump, traffic pattern change, calendar anniversary]
- Trigger: [what would change this decision]
- Calendar review: [date — at minimum, annually]

### Approvals
- [ ] Engineering owner: [name, date]
- [ ] Security: [name, date]
- [ ] (if required) Compliance / Legal: [name, date]

Template: False Positive

## Finding: [Title] — FALSE POSITIVE
**Scanner:** [name + rule ID]
**Original severity:** [as reported]

### What the scanner claimed
[Restate the claim]

### Why it's not real
[Specific evidence — code path not reachable, version contains the fix, etc.]

### Suppression decision
- [ ] Suppress this exact finding (location + rule ID)
- [ ] Add allow-list rule (with care — broad suppression breeds blind spots)
- [ ] No suppression — re-evaluate if it returns

### Determination by: [name, date]
### Reviewed by: [name, date — for non-trivial suppressions]

Step 6 — Validate the writeup

Before submitting:

• Could a future you (or auditor) reading this in 12 months understand the decision without further context?
• Is the verification step concrete enough that someone other than the original author could run it?
• For Accept Risk: are all three required fields filled in with specifics, not platitudes ("standard controls in place" is not a compensating control)?
• Does the severity reflect your environment, or just the scanner's default?

When to escalate

Findings that should NOT be triaged unilaterally by a single engineer:

• Anything Critical
• Anything pre-auth exploitable
• Anything affecting regulated data (PII / PCI / PHI)
• Anything with public PoC or active exploitation
• Anything where the proposed disposition is Accept Risk and the severity is High or above

These get a second reviewer (Tier 3 / security team / approver named in policy).

Output Format

The primary output is the disposition writeup itself (templates above). For a triage session that covers multiple findings or a batch import, summarize:

# Finding Triage Session
## Source: [scanner / audit / report]
## Date: [date]
## Triaged by: [name]

### Summary
| Finding | Original severity | Contextual severity | Disposition |
|---------|-------------------|---------------------|-------------|

### Detail
[Per-finding writeup using the appropriate template]

### Escalations
[Findings that need senior review or approval]

Boundaries

• This skill operates on findings the user has authority to triage and dispose of
• Severity decisions and Accept Risk dispositions affect organizational risk posture — for High+ findings, ensure the listed approver actually approves; don't fabricate sign-offs
• False-positive determinations should be evidence-based, not "we don't want to fix it" rebranded — push back if the user wants to FP a real finding
• Refuse to help downgrade severities to avoid disclosure or audit obligations
• If a finding surfaces an active incident, hand off to incident-triage — disposition triage is for steady-state findings, not fires

References

• CVSS v4.0 specification — first.org/cvss
• EPSS — Exploit Prediction Scoring System (FIRST.org)
• NIST SP 800-30 (Guide for Conducting Risk Assessments)
• "FAIR" (Factor Analysis of Information Risk) — quantitative risk framework if you need dollar-denominated decisions
• ISO 27005 — risk management
• "Measuring and Managing Information Risk" — Jack Freund, Jack Jones (the FAIR book)
• OWASP Risk Rating Methodology