How I Prioritize Vulnerabilities Beyond CVSS

Every vulnerability management program eventually hits the same wall: a scanner returns thousands of findings, most of them scored 'High' or 'Critical' by CVSS, and there is nowhere near enough remediation capacity to fix them all this quarter. If CVSS is the only lens you're using to decide what to fix first, you're prioritizing severity, not risk.

CVSS answers the wrong question

CVSS base score is a measure of theoretical severity: what could happen if this vulnerability were exploited, in the worst case, in a generic environment. It says nothing about whether the vulnerability is being exploited in the wild, whether the affected asset is internet-facing, or whether it sits in front of anything an attacker would actually want. Treating CVSS as a priority queue means you spend your best remediation hours on vulnerabilities that are severe but irrelevant, while something quietly exploitable sits unpatched further down the list.

The model: severity, exploitability, exposure, criticality

I prioritize on four inputs layered on top of each other, in this order:

• Severity (CVSS): the theoretical ceiling of impact.
• Exploitability (EPSS): the probability this specific CVE will be exploited in the next 30 days, based on real-world exploitation activity.
• Known exploitation (CISA KEV): is this CVE already being actively exploited? If it's on the KEV list, it moves to the front of the queue regardless of anything else.
• Asset criticality and exposure: does this sit on a domain controller, an internet-facing service, or a machine holding sensitive data, or is it an isolated test box nobody touches?

A CVSS 7.5 finding on an internet-facing identity system with a high EPSS score and active KEV listing gets fixed today. A CVSS 9.8 finding on an isolated, non-critical asset with near-zero EPSS and no known exploitation gets scheduled instead: it stays on the list, just not at the top.

What this looks like operationally

In practice, this means every finding coming out of a scan gets enriched before it reaches a remediation queue: CVSS from the scanner, EPSS pulled against the CVE, a KEV check, and an asset criticality tag from the CMDB or asset inventory. Findings are then bucketed, not ranked by a single blended score. A KEV hit is its own bucket, full stop; the decision to fix it isn't really a prioritization decision at all.

A vulnerability count without exploitability and exposure context is a to-do list, not a risk assessment.

Where this breaks down

This model only works if the underlying asset inventory and criticality tagging are accurate. If you don't actually know which box is a domain controller versus a disposable dev VM, every downstream prioritization decision inherits that blind spot. In my experience, the actual bottleneck in most vulnerability management programs is asset criticality data quality. It's rarely the scanning, and it's rarely the scoring model.