Finding triage — single finding to defensible disposition
This is a coordinator skill. Other skills surface raw findings; this one normalizes one finding at a time into a disposition with the evidence a reviewer, auditor, or regulator will accept later. Run it once per finding, not per scan.
Inputs come from anywhere: SAST/DAST/SCA scanner output, dependency advisories, [[offensive-reporting]] deliverables, bug bounty reports, [[performing-web-application-vulnerability-triage]], threat hunts, vendor disclosures. Wherever the finding came from, the output shape is the same.
The four dispositions
Every finding ends in exactly one of these, with its required fields filled in. A disposition without its fields is not done.
| Disposition |
Required fields |
| Fixed |
Fix description, deploy plan (where/when), verification method (how you proved it's closed) |
| Deferred |
Deferral reason, new deadline, owner, escalation condition if the deadline slips |
| Accepted Risk |
(1) Why the fix doesn't apply or isn't worth it, (2) compensating controls in place, (3) re-evaluation trigger (date or event) |
| False Positive |
Evidence supporting the determination, scanner rule ID for suppression so it doesn't recur |
"Accepted Risk" and "False Positive" are the two that get challenged in audits — over-document them, not under.
Workflow
- Restate the finding in your own words. CWE/CVE if any, exact location (
file:line, endpoint, ARN, package@version), the preconditions for exploitation, and the concrete impact if exploited. If you can't state the impact, you can't triage it — go back to the source skill.
- Verify reachability. Is the vulnerable code path actually reachable from attacker-controlled input in this deployment? A SQLi in dead code, a CVE in a dependency whose vulnerable function is never called, an IDOR behind an auth wall the tester didn't pass — these change the disposition. Verify with the tool, don't assume. For CVE depth use
[[cve-poc-generator]] or [[performing-cve-prioritization-with-kev-catalog]]; check KEV and EPSS before trusting raw CVSS.
- Apply contextual severity. The scanner's rating is a starting point, not the answer. Adjust for: internet-facing vs internal, regulated/sensitive data in scope, existing compensating controls, exploit maturity (KEV-listed? public PoC?). Document the adjustment and why. Use
[[prioritizing-vulnerabilities-with-cvss-scoring]] or [[triaging-vulnerabilities-with-ssvc-framework]] for a defensible method.
- Assign the disposition and fill its required fields from the table above.
- Document defensibly. Write it so someone with no context can read the ticket in six months and agree with the call. Evidence, not adjectives.
- Escalate High/Critical. Anything you rate High or Critical gets a named secondary reviewer before it closes. Note who and when.
Output format
FINDING: <one-line title> [<source skill / scanner>]
CWE/CVE: <id or n/a> LOCATION: <file:line | endpoint | ARN | pkg@ver>
REACHABLE: <yes/no — evidence>
SEVERITY: <scanner rating> → <adjusted rating> (reason: <...>)
DISPOSITION: <Fixed | Deferred | Accepted Risk | False Positive>
<required fields for that disposition>
ESCALATION: <reviewer + date, or n/a for Low/Medium>
Hand-off
- Translating this for a non-technical audience (exec, customer, legal, board)? Route to
[[security-comms]].
- Rolling many triaged findings into program-level evidence, SLA tracking, or compliance mapping? Route to
[[grc-compliance-privacy-program]].
- Writing it into an engagement deliverable? Route to
[[offensive-reporting]].
Guardrails
- Do not fabricate reachability or impact. If you haven't verified the path, say "unverified" and mark it for follow-up — an honest gap beats a confident guess.
- Do not downgrade a finding to make a number look better. Contextual severity adjusts up as readily as down.
- A False Positive needs evidence, not just disagreement with the scanner.
1---2name: finding-triage3description: Finding triage — single finding to defensible disposition4---56# Finding triage — single finding to defensible disposition78This is a coordinator skill. Other skills surface raw findings; this one normalizes one finding at a time into a disposition with the evidence a reviewer, auditor, or regulator will accept later. Run it once per finding, not per scan.910Inputs come from anywhere: SAST/DAST/SCA scanner output, dependency advisories, `[[offensive-reporting]]` deliverables, bug bounty reports, `[[performing-web-application-vulnerability-triage]]`, threat hunts, vendor disclosures. Wherever the finding came from, the output shape is the same.1112## The four dispositions1314Every finding ends in exactly one of these, with its required fields filled in. A disposition without its fields is not done.1516| Disposition | Required fields |17| --- | --- |18| **Fixed** | Fix description, deploy plan (where/when), verification method (how you proved it's closed) |19| **Deferred** | Deferral reason, new deadline, owner, escalation condition if the deadline slips |20| **Accepted Risk** | (1) Why the fix doesn't apply or isn't worth it, (2) compensating controls in place, (3) re-evaluation trigger (date or event) |21| **False Positive** | Evidence supporting the determination, scanner rule ID for suppression so it doesn't recur |2223"Accepted Risk" and "False Positive" are the two that get challenged in audits — over-document them, not under.2425## Workflow26271. **Restate the finding in your own words.** CWE/CVE if any, exact location (`file:line`, endpoint, ARN, package@version), the preconditions for exploitation, and the concrete impact if exploited. If you can't state the impact, you can't triage it — go back to the source skill.282. **Verify reachability.** Is the vulnerable code path actually reachable from attacker-controlled input in this deployment? A SQLi in dead code, a CVE in a dependency whose vulnerable function is never called, an IDOR behind an auth wall the tester didn't pass — these change the disposition. Verify with the tool, don't assume. For CVE depth use `[[cve-poc-generator]]` or `[[performing-cve-prioritization-with-kev-catalog]]`; check KEV and EPSS before trusting raw CVSS.293. **Apply contextual severity.** The scanner's rating is a starting point, not the answer. Adjust for: internet-facing vs internal, regulated/sensitive data in scope, existing compensating controls, exploit maturity (KEV-listed? public PoC?). Document the adjustment and why. Use `[[prioritizing-vulnerabilities-with-cvss-scoring]]` or `[[triaging-vulnerabilities-with-ssvc-framework]]` for a defensible method.304. **Assign the disposition** and fill its required fields from the table above.315. **Document defensibly.** Write it so someone with no context can read the ticket in six months and agree with the call. Evidence, not adjectives.326. **Escalate High/Critical.** Anything you rate High or Critical gets a named secondary reviewer before it closes. Note who and when.3334## Output format3536```text37FINDING: <one-line title> [<source skill / scanner>]38CWE/CVE: <id or n/a> LOCATION: <file:line | endpoint | ARN | pkg@ver>39REACHABLE: <yes/no — evidence>40SEVERITY: <scanner rating> → <adjusted rating> (reason: <...>)41DISPOSITION: <Fixed | Deferred | Accepted Risk | False Positive>42 <required fields for that disposition>43ESCALATION: <reviewer + date, or n/a for Low/Medium>44```4546## Hand-off4748- Translating this for a non-technical audience (exec, customer, legal, board)? Route to `[[security-comms]]`.49- Rolling many triaged findings into program-level evidence, SLA tracking, or compliance mapping? Route to `[[grc-compliance-privacy-program]]`.50- Writing it into an engagement deliverable? Route to `[[offensive-reporting]]`.5152## Guardrails5354- Do not fabricate reachability or impact. If you haven't verified the path, say "unverified" and mark it for follow-up — an honest gap beats a confident guess.55- Do not downgrade a finding to make a number look better. Contextual severity adjusts up as readily as down.56- A False Positive needs evidence, not just disagreement with the scanner.
26zl