Stop worshipping CVSS: prioritize exploitability and blast radius, not the score

Opinion: CVSS was never meant to decide tomorrow’s patch queue by itself. Yet many organizations still treat 8.0+ as gospel and everything else as “later.” That mindset ships toil, not risk reduction.

Why score-first fails

• Exploit reality ≠ theoretical severity. Medium CVSS vulns are frequently exploited in the wild while some 9.8s never see reliable PoCs.
• Context blind. A 9.0 on an isolated lab host is less urgent than a 7.2 on an internet-exposed gateway with domain creds.
• Backlogs balloon. Tools dump thousands of “critical” findings with no notion of shared libraries, compensating controls, or blast radius.

A sane prioritization formula

Score = Exploitability × Exposure × Impact

• Exploitability: EPSS probability, presence on CISA KEV, public PoCs, exploit kit sightings.
• Exposure: internet-facing? authentication required? reachable from tier-0? EDR coverage? compensating controls?
• Impact: data sensitivity, privilege required/obtained, lateral movement potential, customer-facing disruption.

What to change this quarter

1. Make KEV non-negotiable: anything in KEV on an exposed asset gets a 72-hour SLA (or faster for edge/gateway).
2. Integrate EPSS into ticketing: auto-boost issues with EPSS ≥ 0.3; de-prioritize low-EPSS items behind compensating controls.
3. Tie assets to business services: patch priority inherits the criticality of the service (payments, identity, EHR, etc.).
4. Close the loop with attack surface data: ASM/inventory decides if a vuln is actually reachable from the internet.
5. Batch by blast radius: fix the shared component (library/base image) once; retire entire classes of findings.
6. Report outcomes, not counts: time-to-remediate KEV, exposed attack surface reduced, outages avoided—stop celebrating “# of vulns closed.”

Bottom line: CVSS belongs in the description column. Put exploitability and blast radius in the driver’s seat if you want measurable risk reduction.