finding-triage

Name: finding-triage
Author: briiirussell

320stars36forks

How to install finding-triage?

briiirussell/cybersecurity-skills/finding-triage

$npx -y skills add briiirussell/cybersecurity-skills --skill finding-triage

Installs into the current project.

Summary

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,' 'mitigatio

Files · 1

View on GitHub

SKILL.md

1	# Finding Triage — Single-Finding Disposition with Defensible Justification
2
3	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.
4
5	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.
6
7	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.
8
9	Cross-references:
10	- `vuln-research` for the technical CVE deep-dive that feeds reachability assessment here
11	- `owasp-audit` Three-Disposition rule (the framework this implements per-finding)
12	- `security-comms` for translating the disposition writeup into stakeholder-readable language when the finding has to leave the security context
13	- Any audit skill — this consumes their findings as input
14
15	## Workflow
16
17	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.
18
19	### Step 1 — Restate the finding in your own words
20
21	If the finding came from a scanner, restate what's actually being claimed. Scanners produce noise; restating filters out the boilerplate.
22
23	A good restatement names:
24	- What the issue is (specific weakness — CWE if applicable)
25	- Where it lives (file:line, endpoint, resource ARN, host)
26	- How it could be exploited (preconditions, attacker capability needed)
27	- Impact if it were exploited (data loss, privilege escalation, availability)
28
29	If you can't restate it clearly, you don't understand it yet. Ask the user for context.
30
31	### Step 2 — Is this actually true?
32
33	Half of automated-scanner findings are false positives by volume. The triage:
34
35	\| Question \| If yes \| If no \|
36	\|---\|---\|---\|
37	\| Does the vulnerable code path exist as described? \| Continue \| False positive — scanner found a phantom \|
38	\| Is the code path reachable from any attacker-controllable input? \| Continue \| Continue, but severity drops \|
39	\| Does the exploit precondition match your environment? \| Continue \| Severity drops or false positive \|
40	\| Is there a public PoC, or has anyone confirmed this in the wild? \| Severity stays / rises \| Severity may drop \|
41	\| Are existing controls (WAF, auth, network segmentation) preventing exploitation? \| Severity drops; controls become the mitigation \| Severity stays \|
42
43	Common false-positive patterns:
44	- SAST flag on test files or dead code
45	- Dependency scanner flag on package in `devDependencies` only — runtime-unreachable (see `dependency-audit` reachability column)
46	- DAST flag on a path that returns 404 in your real environment but was confused by SPA routing
47	- Outdated advisory — vendor silently fixed it before the CVE; your version contains the fix
48	- Pattern match on code that looks vulnerable but is inside a function never invoked
49
50	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.
51
52	### Step 3 — Contextual severity
53
54	The scanner's CVSS or severity rating is a starting point, not the answer. Adjust for your context.
55
56	Factors that increase severity beyond the rating:
57	- Vulnerable endpoint is internet-facing, not internal
58	- Authentication preconditions are easy to satisfy (open signup) in your app, even if the CVE assumes "authenticated"
59	- Vulnerable data is regulated (PII, PCI cardholder data, PHI) — exploitation has reportable-incident consequences
60	- Public PoC exists or active exploitation observed
61	- Vulnerable component is in the critical path (every request touches it)
62	- Compensating controls are missing or weak
63
64	Factors that decrease severity below the rating:
65	- Vulnerable code path is unreachable in your usage (read the patch, grep for the function — see `vuln-research`)
66	- Strong compensating controls (WAF blocks the payload pattern, network segmentation prevents reach)
67	- Exploit req

briiirussellPublisher · 30 listings

Preview

briiirussell/cybersecurity-skills

# 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 deser

The dispositions match `owasp-audit`'s Three-Disposition rule: **Fixed**, **Deferred**, or **Accepted Risk**. False positive is a fourth — but it isn't a dispos

This skill works on findings from any source: SAST output, DAST scanner, dependency advisory, manual audit, threat-hunt hit, pentest report, vendor disclosure,

Repobriiirussell/cybersecurity-skills

LicenseMIT

TypeSkills

CategorySecurity

UpdatedMay 2026

Repo stars320

First seenJul 22, 2026

People who liked this also viewed

6 picks

Type

finding-triage

320stars36forks

View on GitHub

How to install finding-triage?

briiirussell/cybersecurity-skills/finding-triage

$npx -y skills add briiirussell/cybersecurity-skills --skill finding-triage

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Finding Triage — Single-Finding Disposition with Defensible Justification
2
3	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.
4
5	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.
6
7	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.
8
9	Cross-references:
10	- `vuln-research` for the technical CVE deep-dive that feeds reachability assessment here
11	- `owasp-audit` Three-Disposition rule (the framework this implements per-finding)
12	- `security-comms` for translating the disposition writeup into stakeholder-readable language when the finding has to leave the security context
13	- Any audit skill — this consumes their findings as input
14
15	## Workflow
16
17	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.
18
19	### Step 1 — Restate the finding in your own words
20
21	If the finding came from a scanner, restate what's actually being claimed. Scanners produce noise; restating filters out the boilerplate.
22
23	A good restatement names:
24	- What the issue is (specific weakness — CWE if applicable)
25	- Where it lives (file:line, endpoint, resource ARN, host)
26	- How it could be exploited (preconditions, attacker capability needed)
27	- Impact if it were exploited (data loss, privilege escalation, availability)
28
29	If you can't restate it clearly, you don't understand it yet. Ask the user for context.
30
31	### Step 2 — Is this actually true?
32
33	Half of automated-scanner findings are false positives by volume. The triage:
34
35	\| Question \| If yes \| If no \|
36	\|---\|---\|---\|
37	\| Does the vulnerable code path exist as described? \| Continue \| False positive — scanner found a phantom \|
38	\| Is the code path reachable from any attacker-controllable input? \| Continue \| Continue, but severity drops \|
39	\| Does the exploit precondition match your environment? \| Continue \| Severity drops or false positive \|
40	\| Is there a public PoC, or has anyone confirmed this in the wild? \| Severity stays / rises \| Severity may drop \|
41	\| Are existing controls (WAF, auth, network segmentation) preventing exploitation? \| Severity drops; controls become the mitigation \| Severity stays \|
42
43	Common false-positive patterns:
44	- SAST flag on test files or dead code
45	- Dependency scanner flag on package in `devDependencies` only — runtime-unreachable (see `dependency-audit` reachability column)
46	- DAST flag on a path that returns 404 in your real environment but was confused by SPA routing
47	- Outdated advisory — vendor silently fixed it before the CVE; your version contains the fix
48	- Pattern match on code that looks vulnerable but is inside a function never invoked
49
50	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.
51
52	### Step 3 — Contextual severity
53
54	The scanner's CVSS or severity rating is a starting point, not the answer. Adjust for your context.
55
56	Factors that increase severity beyond the rating:
57	- Vulnerable endpoint is internet-facing, not internal
58	- Authentication preconditions are easy to satisfy (open signup) in your app, even if the CVE assumes "authenticated"
59	- Vulnerable data is regulated (PII, PCI cardholder data, PHI) — exploitation has reportable-incident consequences
60	- Public PoC exists or active exploitation observed
61	- Vulnerable component is in the critical path (every request touches it)
62	- Compensating controls are missing or weak
63
64	Factors that decrease severity below the rating:
65	- Vulnerable code path is unreachable in your usage (read the patch, grep for the function — see `vuln-research`)
66	- Strong compensating controls (WAF blocks the payload pattern, network segmentation prevents reach)
67	- Exploit req

briiirussellPublisher · 30 listings

Preview

briiirussell/cybersecurity-skills

# 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 deser

The dispositions match `owasp-audit`'s Three-Disposition rule: **Fixed**, **Deferred**, or **Accepted Risk**. False positive is a fourth — but it isn't a dispos

This skill works on findings from any source: SAST output, DAST scanner, dependency advisory, manual audit, threat-hunt hit, pentest report, vendor disclosure,

Repobriiirussell/cybersecurity-skills

LicenseMIT

TypeSkills

CategorySecurity

UpdatedMay 2026

Repo stars320

First seenJul 22, 2026

People who liked this also viewed

6 picks

Type