Vulnerability Triage

Vulnerability scanners produce volume, not priority. Effective triage cuts the list to an actionable queue engineers can work without burning out or ignoring legitimate risk.

Start with Exploitability, Not CVSS

CVSS base scores measure theoretical severity in an ideal attacker environment. They do not measure your environment. For each finding, answer these questions before assigning internal priority:

• Is the vulnerable component reachable from an untrusted input source (public internet, anonymous API, user-controlled data)?
• Does exploiting it require authentication? If yes, what privilege level?
• Is there a public proof-of-concept exploit or active in-the-wild exploitation (check CISA KEV catalog)?
• Does your deployed configuration match the vulnerable configuration? (Example: a path traversal in a feature your app does not use.)

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

Assign Internal Severity

Use four tiers:

• 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 requires chaining one 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.

Distinguish False Positives Systematically

Do not mark a finding as a false positive based on intuition alone. Document the specific reason:

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

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

Deduplication and Grouping

Scanners frequently report the same root cause through multiple symptoms. Before building a fix list, group findings by root cause (example: all XSS findings from the same template engine misconfiguration). One fix may close ten findings — identify these first for maximum leverage.

Tracking and SLAs

Every finding above Low needs a ticket with the internal severity, the finding source, the assigned owner, and the SLA due date. Track SLA breach rate as an engineering health metric. Escalate to engineering leadership when Critical or High findings miss SLA — do not silently extend deadlines.