CVSS, EPSS and KEV: prioritising what to patch

"What's the difference between CVSS and EPSS, and which drives your patching?"

What it is

Three systems that answer three different questions about a vulnerability, and conflating them is the most common failure in vulnerability management.

CVE is an identifier. CVE-2024-3094 names a specific vulnerability. It says nothing about severity or risk.

CVSS (Common Vulnerability Scoring System) scores intrinsic severity 0 to 10, from characteristics of the flaw itself: attack vector, complexity, privileges required, and the impact on confidentiality, integrity and availability. It answers "how bad would this be if exploited?"

EPSS (Exploit Prediction Scoring System, maintained by FIRST) gives a probability of exploitation in the wild in the next 30 days, from a model trained on observed exploitation data. It answers "how likely is this to be exploited?"

KEV (CISA's Known Exploited Vulnerabilities catalogue) is a list of vulnerabilities with confirmed active exploitation. It answers "is this being exploited right now?"

Severity, likelihood, and observed fact. Three different questions, and only the combination is a priority.

The problem it solves

A mid-size organisation's scanner reports thousands of open findings, and a large share of them score CVSS 7.0 or above. "Patch all criticals within seven days" is therefore a policy that either cannot be executed or is executed by patching whatever happens to be easiest.

Meanwhile, the published research is consistent that only a small minority of vulnerabilities are ever exploited in the wild. Cyentia and Kenna's Prioritization to Prediction series has repeatedly put the figure in the range of a few percent. So a CVSS-only policy spends most of its effort on things that will never be attacked, while something with a modest CVSS score and active exploitation sits in the queue.

The point of EPSS and KEV is not to patch less. It is to patch the right things first, with the same capacity.

Mechanics

What each score is made of

CVSS base score combines exploitability metrics (attack vector, attack complexity, privileges required, user interaction) with impact metrics (confidentiality, integrity, availability). Crucially it is environment-agnostic: the same flaw scores identically whether it is on your internet-facing gateway or on a laptop in a locked drawer.

CVSS also defines Temporal and Environmental metric groups that adjust for exploit maturity and for your deployment. Almost nobody uses them, which is a large part of why CVSS gets blamed for being context-free: the context exists in the standard and organisations do not populate it.

EPSS produces a probability in $[0, 1]$, refreshed daily, from a model trained on features of the vulnerability (vendor, CWE type, published exploit code, references, age) against observed exploitation telemetry. Two properties matter operationally: it is highly skewed (most CVEs score below 0.01), and it changes over time, so yesterday's low score can rise sharply when exploit code is published.

KEV is not a score, it is a catalogue with an evidence threshold: CISA adds a CVE when there is reliable evidence of active exploitation. For US federal agencies it comes with binding remediation deadlines, which is why it is a useful external anchor for policy even outside government.

The prioritisation formula

The mature ordering, and the answer to the question:

1. KEV                      -> patch now, emergency change if needed
2. High EPSS x exposed      -> patch this week
3. High CVSS x exposed x sensitive data  -> patch this sprint
4. Everything else          -> patch on the normal cycle

The multiplication is the point. Neither score is a priority on its own, because neither knows anything about your environment. The variables you supply are:

Exposure: internet-facing, internal, or air-gapped.
Reachability: is the vulnerable code path actually invoked? A vulnerable library function you never call is a finding, not a risk. This is what reachability analysis in modern SCA tools measures, and it typically eliminates a large fraction of findings.
Data sensitivity: what does this system hold.
Compensating controls: WAF rule, network segmentation, feature flag.

def priority(finding, asset):
    """Ordering, not a score. Resist the urge to produce a single number:
    the ordering is defensible to an auditor and a composite number is not."""
    if finding.cve in KEV:
        return P0                                        # observed exploitation

    if not asset.internet_facing and not asset.holds_sensitive_data:
        return P3                                        # exposure gates everything

    if finding.epss >= 0.10 and asset.internet_facing:
        return P1                                        # ~top 1% of EPSS scores

    if finding.cvss >= 9.0 and asset.holds_sensitive_data:
        return P2

    if finding.reachable is False:                       # from SCA reachability
        return P3                                        # present but never called

    return P3

An EPSS threshold of 0.10 sounds low and is not: because the distribution is so skewed, a score of 0.10 places a vulnerability in roughly the top 1 percent by predicted exploitation. Knowing that the threshold is a percentile in disguise is a good depth signal.

Patch SLAs keyed to three variables, not one

The junior policy is one column. The mature policy is a matrix:

	Internet-facing, sensitive data	Internet-facing	Internal	Isolated
KEV	24 hours	48 hours	7 days	30 days
EPSS ≥ 0.10	7 days	14 days	30 days	Next cycle
CVSS ≥ 9.0	14 days	30 days	60 days	Next cycle
Everything else	30 days	60 days	90 days	Next cycle

Saying "we patch all criticals in seven days" without the exposure and data columns is the answer that marks someone as having read the standard rather than run the programme.

The rule underneath everything

Your patching velocity is bounded by your inventory accuracy. You cannot patch what you do not know you run. Most organisations fail at step one, and the honest version of a vulnerability management answer starts there:

A software bill of materials per artifact, generated at build time.
A registry mapping running artifacts to their SBOMs, so "what runs this library" is a query rather than an investigation.
Golden base images rebuilt on upstream CVE and redeployed immutably, never patched in place.
Coverage as a metric: what fraction of running workloads have a current SBOM.

A worked example: the four hours after a critical CVE drops

"A critical CVE lands in a library you use. Walk the first four hours."

0 to 30 minutes: inventory. The only question that matters first is do we run it, and where.

# From the SBOM registry, not from a scanner sweep, because you need this
# in minutes and a sweep takes hours.
$ sbom-query --package "org.example:widget" --version "<2.4.1"
  payments-api      2.3.0   internet-facing  PCI-scope    12 pods
  batch-reconciler  2.3.0   internal         PCI-scope     2 pods
  legacy-reporting  1.9.4   internal         no            1 pod   (not in range)

If this takes four hours instead of thirty minutes, that is the finding of the incident, and it is more important than the CVE.

30 to 60 minutes: exposure and reachability. Is the vulnerable code path reachable from untrusted input? A deserialisation flaw in a code path we never invoke is a different problem from one in the request handler. Check KEV and EPSS: KEV membership or a rising EPSS score escalates immediately.

60 to 120 minutes: mitigate before you patch. Patching takes as long as it takes; mitigation can be minutes:

A WAF rule blocking the exploit pattern.
A feature flag disabling the vulnerable endpoint.
A network policy cutting egress the exploit would need.
Rate limiting to make exploitation impractical.

Mitigate first, patch second is the same discipline as an incident: stop the bleeding before you diagnose. It is the sequencing to say out loud.

120 to 210 minutes: patch and verify. Bump the library, run the test suite, build a new immutable image, canary, roll. Then verify by inventory, not by assumption: re-query the SBOM registry and confirm no running workload reports the vulnerable version. The gap between "we deployed the fix" and "nothing vulnerable is running" is where stragglers live: a paused deployment, a scaled-to-zero service that comes back later, a job image nobody thought of.

210 to 240 minutes: communicate. A short written note: what it is, whether we were exposed, what we did, what remains, and when. Customers and leadership need this before they read about it elsewhere, and writing it forces you to notice what you have not confirmed.

The follow-up that matters is not "patch faster". It is whichever step took longest. If inventory took two hours, the fix is the SBOM registry. If mitigation was not available, the fix is a WAF you can write rules for quickly. If stragglers lingered, the fix is deployment coverage reporting.

Production evidence

FIRST maintains both CVSS and EPSS, publishes the EPSS model documentation and daily scores, and is explicit that EPSS measures likelihood of exploitation rather than severity and should be used alongside CVSS rather than instead of it.

CISA's KEV catalogue carries an evidence threshold (reliable evidence of active exploitation) and, under Binding Operational Directive 22-01, mandatory remediation timelines for US federal civilian agencies. That directive is the clearest official statement that observed exploitation should outrank intrinsic severity.

Cyentia and Kenna Security's Prioritization to Prediction series is the empirical basis for the claim that only a small percentage of published vulnerabilities are ever exploited in the wild, and that severity-based prioritisation performs poorly compared with likelihood-based approaches on both coverage and efficiency.

Reachability analysis is now standard in commercial and open-source software composition analysis tools, and vendors consistently report that it eliminates a large majority of raw findings by showing the vulnerable code path is never invoked.

The debate

The case for CVSS-only: it is simple, universally understood, available for every CVE immediately on publication, and auditors and customers ask about it. EPSS requires explanation, and a policy of "we deprioritised this critical because EPSS was low" is a sentence you may have to defend after an incident.

The case against: it prioritises by a number that knows nothing about your environment, so it spends most of your remediation capacity on vulnerabilities that will never be attacked, while genuinely exploited issues with moderate scores wait.

The honest risk in the EPSS approach is model risk: EPSS predicts, and a prediction can be wrong for the one that matters. The mitigation is that EPSS is never the only input, KEV overrides it, and exposure gates everything.

My position: KEV first, because observed exploitation beats any prediction. Then EPSS multiplied by exposure, because likelihood without exposure is not risk. Then CVSS for the long tail. Publish the SLA matrix keyed to exposure and data sensitivity rather than to severity alone, and be able to explain the policy to an auditor, because "we used a probability model" needs the reasoning written down before the incident, not after.

This prioritisation is the wrong approach in a regulated environment that mandates a specific severity-based SLA regardless of context, where the compliance requirement is the requirement; and in a small estate where you can simply patch everything on a fast cycle, where prioritisation machinery costs more than it saves.

Follow-up Q&A

"What's the difference between CVSS and EPSS, and which drives your patching?" CVSS scores intrinsic severity: how bad it would be if exploited. EPSS estimates the probability of exploitation in the wild in the next 30 days. They answer different questions and neither is a priority on its own, because neither knows anything about my environment. My ordering is KEV first, since observed exploitation beats any prediction; then EPSS multiplied by exposure; then CVSS for the long tail. Saying "we patch all criticals in seven days" without exposure and data-sensitivity context is the junior answer.

"Why not just patch everything with CVSS above 7?" Because that is most of the catalogue and you do not have the capacity, so in practice you patch whatever is easiest and call the policy satisfied. The published research consistently finds that only a few percent of vulnerabilities are ever exploited, so severity-based prioritisation spends the bulk of remediation capacity on things nobody will attack while genuinely exploited issues with moderate scores wait in the queue.

"A critical CVE drops in a library you use. Walk the first four hours." Inventory first: which running workloads use the affected version, and are they internet-facing. Then exposure and reachability, plus a KEV and EPSS check to set urgency. Then mitigate before patching, because a WAF rule or a feature flag takes minutes and a patch takes hours. Then patch, canary, roll, and verify by inventory rather than by assumption, because stragglers are where the exposure survives. Then communicate in writing. And the retrospective focuses on whichever step took longest, which is usually inventory.

"What are the risks of relying on EPSS?" It is a prediction, so it can be wrong about the one that matters, and it changes daily, so a decision made on Monday's score may be stale by Friday. Mitigations: KEV always overrides EPSS, re-evaluate scores continuously rather than at triage time only, never use EPSS alone without exposure, and document the policy so a deprioritisation decision is defensible after the fact. The failure to avoid is treating a low EPSS as a permanent verdict.

"How do you know what you're running?" A software bill of materials generated at build time for every artifact, stored in a registry keyed to running workloads, so "who uses this library" is a query rather than an investigation. Golden base images rebuilt on upstream CVE and redeployed immutably rather than patched in place. And SBOM coverage as a tracked metric, because your patching velocity is bounded by your inventory accuracy, and most organisations fail at that step rather than at the patching step.

Common misconceptions

The most common is that CVSS is a risk score. It is a severity score, and risk is severity multiplied by likelihood multiplied by exposure. CVSS supplies exactly one of the three.

The second is that EPSS replaces CVSS. FIRST is explicit that they are complementary: likelihood and severity are different axes, and a high-likelihood, low-impact vulnerability is not the same as a low-likelihood, catastrophic one.

The third is that KEV is a small edge case. It is the highest-signal input you have, because it is not a model output at all: it is a record that someone is actually being attacked with this.

Interview delivery note

Say this: "CVE identifies, CVSS scores intrinsic severity, EPSS predicts the probability of exploitation in the next 30 days, and KEV is CISA's catalogue of what's confirmed to be actively exploited. Three different questions, and none of them is a priority on its own because none of them knows anything about my environment. My ordering is KEV first, because observed exploitation beats any prediction, then EPSS times exposure, then CVSS for the long tail."

Then the sentence that separates it from a textbook answer: "'we patch all criticals in seven days' without exposure and data-sensitivity context is the junior answer, because most of the catalogue is CVSS 7 or above and only a few percent of vulnerabilities are ever exploited. I'd publish an SLA matrix keyed to severity, exposure and data sensitivity together."

The depth signal is the constraint underneath: "and the honest limit is that patching velocity is bounded by inventory accuracy. Most organisations fail at knowing what they run, not at applying the patch, so the first investment is an SBOM registry that answers 'who uses this library' in minutes."

The Staff & Team Lead Interview Reference