Vulnerability triage

Vulnerability Triage

Vulnerability scanners produce volume, not priority. Effective triage cuts the list to an actionable queue engineers can work without burning out or quietly ignoring legitimate risk. The costly mistake this skill prevents is sorting by CVSS descending - which puts an unreachable library bug ahead of a trivially exploitable flaw on the public edge, and spends the team's scarce patching capacity in exactly the wrong order.

Operating procedure

Grouping comes before scoring because one root-cause fix can close ten findings; scoring before grouping wastes ten triage passes on one bug.

Step 1: Gather inputs

• The finding list with source (scanner, pentest, bounty) and reported CVSS per item.
• An exposure map: which services are internet-facing, which are internal-only, and what sits behind VPN, WAF, or MFA. If none exists, build a rough one from the load balancer and DNS config and label it a guess.
• Deployed versions and configuration for the affected components - the vulnerable config often is not the deployed config.
• Access to the CISA KEV catalog and exploit-availability data for the findings in question.
• The team's remediation capacity, so SLAs are commitments rather than fiction.

Step 2: Deduplicate and group by root cause

Scanners report the same root cause through multiple symptoms. Group findings by shared cause (example: every XSS finding traced to the same template-engine misconfiguration) before scoring anything. One fix may close ten findings - identify these first for maximum leverage.

Step 3: Score exploitability, not just CVSS

CVSS base scores measure theoretical severity in an ideal attacker environment, not this environment. Use the standard bands only as the scanner's starting label - 9.0-10.0 Critical, 7.0-8.9 High, 4.0-6.9 Medium, 0.1-3.9 Low - then answer four questions per finding group before assigning internal priority:

• Is the vulnerable component reachable from an untrusted input source (public internet, anonymous API, user-controlled data)?
• Does exploitation require authentication? At what privilege level?
• Is there a public proof-of-concept, or active in-the-wild exploitation (check the CISA KEV catalog)? KEV-listed findings on reachable components jump to the top of their tier regardless of score.
• Does the deployed configuration match the vulnerable configuration (a path traversal in a feature the app does not use is a different conversation)?

The governing rule: a CVSS 9.8 in an internal-only admin service behind VPN with MFA is lower priority than a CVSS 6.5 on a public unauthenticated endpoint.

Step 4: Assign internal severity with SLAs

• Critical: remotely exploitable, no auth required, leading to RCE, data exfiltration, or full account takeover. Fix within 24 hours.
• High: exploitable with low privilege or one chaining step, significant data exposure or service disruption possible. Fix within 7 days.
• Medium: requires significant user interaction or specific non-default config, limited impact scope. Fix within 30 days.
• Low: defense-in-depth improvement, informational, or requires physical access. Schedule in the next sprint cycle.

Step 5: Document false positives systematically

Never mark a false positive on intuition. Record the specific reason:

• Component not deployed in this environment.
• Vulnerable code path is dead code - reference the specific unreachable call path.
• A compensating control prevents exploitation - name the control and where it is enforced.

False-positive decisions on Critical and High findings require a second reviewer.

Step 6: Ticket, track, escalate

Every finding above Low gets a ticket with internal severity, finding source, assigned owner, and SLA due date. Track SLA breach rate as an engineering health metric. When a Critical or High misses its SLA, escalate to engineering leadership - never silently extend the deadline, because a slipped deadline nobody sees is a risk acceptance nobody approved.

Worked example: two findings, inverted priority

	Finding A	Finding B
Report	RCE in an admin service library, CVSS 9.8	IDOR on a customer API endpoint, CVSS 6.5
Reachability	Internal-only, behind VPN + MFA	Public internet, unauthenticated
Exploit status	No public PoC, not in KEV	Trivial to reproduce from the bounty report
Config match	Vulnerable module loaded but feature unused	Deployed exactly as reported
Internal severity	High - RCE still warrants urgency, but exploitation requires a VPN-compromise chain first. Fix within 7 days.	Critical - anonymous access to other customers' data, live today. Fix within 24 hours.

Verdict: fix B first. Sorting by CVSS would have inverted this - the 9.8 would consume the emergency window while customer data sat exposed behind the 6.5.

Deliverable

Produce a triage queue containing: findings grouped by root cause with the leverage fixes flagged, each group's internal severity with the exploitability rationale (reachability, auth requirement, exploit availability, config match), the SLA due date and owner per group, and a false-positive log with documented reasons and second-reviewer sign-off for Critical/High dismissals.

Do NOT

• Do not sort the queue by CVSS descending - that is the failure mode this skill exists to prevent.
• Do not triage finding-by-finding before grouping by root cause; it burns effort and hides leverage fixes.
• Do not dismiss a finding as a false positive without a documented, specific reason - intuition dismissals are how real vulnerabilities get archived.
• Do not treat "not in KEV, no public PoC" as safe; it lowers urgency, it does not remove the finding.
• Do not silently extend SLA deadlines; escalate misses so risk acceptance is explicit and owned.
• Do not let a compensating control both downgrade a finding and go unnamed - an unnamed control cannot be verified and will eventually be removed by someone who never knew it mattered.

Quality bar

• Every finding group carries an internal severity that cites reachability, auth requirement, exploit availability, and config match - not a copied CVSS number.
• Root-cause groups exist, and at least the top leverage fix is identified.
• Every Critical maps to a 24-hour SLA, High to 7 days, Medium to 30 days, with a named owner each.
• Every false positive has a documented reason from the accepted list, and Critical/High dismissals show a second reviewer.
• SLA breach rate is reported, not just individual ticket states.

Escalation

Evidence of active exploitation - KEV listing plus matching anomalous logs, or a bounty reporter demonstrating live access - turns triage into incident response: route to sev-triage immediately. Design-stage threat enumeration for unshipped features belongs with threat-model-stride; hands-on review of suspect code with secure-code-review; leaked credentials discovered inside findings with secrets-hygiene.