CVSS, EPSS, KEV: three numbers so you stop fixing vulnerabilities in the wrong order

A team that patches vulnerabilities by descending CVSS score works hard and reduces little risk. Here is why, and what to do instead.

CVSS: severity, not risk

The CVSS score (0 to 10) describes a flaw in the abstract: attack vector (network, adjacent, local, physical), complexity, privileges required, user interaction, impact on confidentiality, integrity and availability. It is published by the NVD and by the vendor, and almost never changes.

What it does not say: whether anyone actually exploits the flaw, and whether your deployment exposes it. Thousands of CVEs rated 9 or 10 have never been exploited. And a 7.5 exploitable remotely without authentication can be far more urgent than a 9.8 that requires local access.

The attack vector is the most useful part of the score. A “network” flaw on an internet-facing service has nothing in common with a “local” flaw on a machine with no interactive users.

EPSS: the probability of exploitation

EPSS (Exploit Prediction Scoring System, published by FIRST) gives each CVE a probability, from 0 to 1, of being exploited within the next thirty days. It is recomputed daily from real signals: public exploit code, mentions, observed activity.

The distribution is very uneven: the vast majority of CVEs have an EPSS below 1%, and a few hundred concentrate most of the exploitation. Sorting by descending EPSS is therefore a very effective filter: it isolates the flaws that stand a reasonable chance of being used against you.

Its limit: it measures attackers’ interest in a flaw, not your exposure to it.

KEV: what is already exploited

The KEV catalogue (Known Exploited Vulnerabilities, maintained by CISA) lists CVEs for which real exploitation has been confirmed, with a remediation deadline for US federal agencies. It also flags those used by ransomware.

A CVE in KEV is no longer a hypothesis. If it affects a component you expose, it goes to the top, whatever its CVSS.

The three together, then context

A simple rule fits in four lines.

1. In KEV and reachable from the internet: fix today.
2. High EPSS and network vector: this week.
3. Critical CVSS but low EPSS and local vector: schedule with routine updates.
4. The rest: at the pace of maintenance cycles.

Lines 1 and 2 contain words the three scores do not know: “reachable from the internet”. That is where context comes in. The same CVE on a public web server and on a batch-processing machine in a private subnet does not carry the same urgency. And if the public machine carries a role that reads a customer database, the urgency rises again.

That is the principle of attack paths: the vulnerability is one link, and its importance depends on the links around it. Log4Shell on an isolated server is an update; Log4Shell on a public server that can assume a data-access role is an open door.

In practice

• Import EPSS and KEV into your vulnerability inventory, not only CVSS. Both are public and free.
• Add each machine’s real network exposure, not the one on the architecture diagram: public address, security group, load balancer in front.
• Add what the machine can reach: role, identity, databases, buckets.
• Handle first the flaws that combine known exploitation, exposure and access to something valuable.

In Ctadel, the vulnerability scanner reads the packages installed on a copy of the disks, attaches to each CVE its CVSS, its EPSS and its presence in KEV, and the attack-path engine adds exposure and target to produce a risk score from 1 to 100. The details are in Severity and score.