Vulnerability Prioritization: Combining KEV, EPSS and Reachability

Three thousand versus twenty

A full scan reports three thousand findings, six hundred of them rated high or critical. Security sends the list to engineering. Engineering looks at it and asks an entirely reasonable question: which one first?

If that question has no answer, two outcomes typically follow: the list is shelved indefinitely, or the team works mechanically down by severity, spending most of its effort on items that carry little real risk. Neither is good.

Prioritization methodology exists to close that gap. The key insight is this: no single metric can answer the question, because they are not answering the same question at all.

Four criteria, four questions

### CVSS: how severe is this vulnerability in theory?

CVSS scores the technical characteristics of the vulnerability itself — attack vector, complexity, privileges required, scope of impact. Its value is a severity baseline that is comparable across organizations.

Its limitation: CVSS describes what happens if exploited. It says nothing about whether it will be exploited, or whether it can be exploited in your environment. A 9.8 with no public exploit code, in a code path your deployment never reaches, may carry far less real risk than a 6.5 under active mass exploitation.

Treating CVSS as the sole ordering criterion is the most common mistake in vulnerability management.

### KEV: is this vulnerability being exploited right now?

CISA's Known Exploited Vulnerabilities catalog records vulnerabilities with concrete evidence of use in real attacks.

This is a binary, high-confidence signal. An entry in KEV means attacks are already happening, not theorized. For enterprises, KEV matches should take top priority regardless of CVSS — a 7.5 being actively exploited is far more urgent than a 9.8 nobody has touched.

KEV's limitation is coverage: it only contains observed exploitation. Newly emerged vulnerabilities, or those used in targeted attacks, will not appear immediately.

### EPSS: what is the probability of exploitation in the next thirty days?

EPSS, maintained by FIRST, uses a machine learning model to predict the probability that a vulnerability will be exploited within 30 days, scored from 0 to 1.

It fills exactly the gap KEV leaves: KEV tells you what is already being exploited, EPSS tells you what likely will be. Model inputs include vulnerability characteristics, availability of exploit code, and community discussion signals.

Practical value: the vast majority of vulnerabilities score very low on EPSS (fractions of a percent). What deserves attention is the small set scoring notably high — which lets you quickly isolate high-probability targets among thousands.

### Reachability: can this vulnerability actually be triggered in your code?

The first three criteria are all about the vulnerability. Reachability answers a question about you: does your code actually call the vulnerable function? Are the parameters along that path attacker-controllable? Do the trigger conditions hold under your configuration?

This is the only criterion that dramatically reduces workload. In practice, many component vulnerabilities sit in functionality you never use — the dependency is there, but that code will never execute. Identifying these can shrink the remediation list by an order of magnitude.

This is also what VEX is for: standardizing the “not affected” judgment as output, so downstream consumers do not have to repeat the same analysis.

Using them together

The right relationship between the four is not “pick one” but layered filtering:

Layer 1 · Fix immediately: KEV matches. Under active exploitation, no debate, straight to the emergency process.

Layer 2 · Fix this cycle: high EPSS (above your chosen threshold) plus reachability confirmed as triggerable. Not yet mass-exploited, but probability is significant and the risk genuinely exists in your environment.

Layer 3 · Schedule: high CVSS, reachable, low EPSS. Real, but without urgent external pressure — fold into normal iteration.

Layer 4 · Record and monitor: assessed as not affected via reachability. Not ignored — record the reasoning (generate VEX) and re-evaluate when the environment changes. Code that is unreachable today may become reachable after tomorrow's refactor.

The payoff of this layering is that it turns “three thousand to fix” into “a dozen urgent, several dozen this cycle, the rest scheduled and monitored” — a scale a team can actually execute against.

Details that matter in practice

Set your own thresholds; do not copy someone else's. What EPSS score counts as high, what CVSS floor to use, depends on your industry, exposure and team capacity. An internet-facing core service and an internal tool should not share thresholds.

Preserve judgments; do not redo the work. When a team spends time establishing “we are not affected by this one”, that conclusion should be recorded, reused, and re-triggered when the environment changes. VEX is the standard vehicle for exactly this.

Fixing is not the only option. Upgrade, patch, configuration mitigation, isolation, component replacement — the cost and timeline of these differ substantially. The output of prioritization should be “which remediation path does this take”, not merely “this needs fixing”.

Watch the aggregate trend. Beyond individual findings, what deserves attention is whether the backlog is converging: the trend line of open findings, mean time to remediate, the share of items past their deadline. Those metrics tell you whether your vulnerability management is improving or decaying.

From “found” to “resolved”

Maturity in vulnerability management shows not in how many findings the scanner produces, but in what proportion of those findings receive a sound disposition.

Detection is no longer the bottleneck — current tooling can report far more than any team can process. The real bottleneck is judgment: which are genuine risks, which can wait, which need no fix at all. And the quality of that judgment depends on whether you use these four criteria in combination.

---

Further reading: Configuring SCA gates in CI pipelines · CVSS, EPSS and VEX entries in our Open Source & SBOM Guide · Reachability analysis in CleanSource SCA