CVSS, EPSS, KEV: which vulnerability should you fix first?

Introduction

A scan report on a mid-sized perimeter easily runs to a few hundred lines. A normal operations team fixes a few dozen a month, in between releases. That gap does not close by working harder. It gets managed by choosing.

And the way most organizations choose has not changed in fifteen years: sort by CVSS score, descending, handle the "criticals", then the "highs" if the quarter allows. It is simple, and easy to defend in a steering committee. It is also, and the numbers back this up, one of the least efficient ways to spend remediation time.

This article explains what the three public indicators everyone talks about (CVSS, EPSS, KEV) actually measure, what none of them knows, and the triage rule we apply ourselves. It fits in one table, and it starts with a question that is in none of the three: can this be reached from the Internet?

The problem: too many CVEs, nearly all of them harmless

More than 40,000 CVEs were published in 2024, and 2025 broke that record again. Nobody reads that. Nobody patches that either.

The important point lies elsewhere: only a small minority of those vulnerabilities will ever be exploited for real. The studies FIRST cites in the EPSS documentation put that share at between 2 and 7% of published vulnerabilities. The same documentation notes that an organization manages to fix, depending on the month, between 5 and 20% of its known vulnerabilities.

Put the two figures side by side. Remediation capacity is in the same range as the volume that is actually dangerous. So the problem is not a shortage of hands, it is where you point them. A team that fixes 10% of its backlog with good aim is better protected than a team that fixes 40% by following the order of the report.

CVSS: severity, not risk

CVSS (Common Vulnerability Scoring System) is maintained by FIRST. Version 4.0 dates from November 1, 2023, but the vast majority of scores you will come across are still 3.1. The scale is familiar: 0 to 10, "critical" from 9 upward.

What gets forgotten is what the score measures. The FIRST user guide says it in so many words: the base score measures severity, not risk. It answers "if this flaw gets exploited, in the reasonable worst case, how bad is it and how easy is it?". It does not answer "is someone exploiting it right now?", and even less "is it bad for us?".

The standard does provide the means to answer. CVSS 4.0 has four metric groups:

• Base: the intrinsic characteristics of the flaw. This is the figure published by the NVD and by vendors.
• Threat: exploit maturity (nothing reported, public proof of concept, attacks observed).
• Environmental: your context. Is the component exposed? Does confidentiality matter on this system?
• Supplemental: extra information (automatable, recovery effort) that does not change the score.

Version 4.0 even introduced a naming scheme so that people know what they are looking at: CVSS-B for the base score alone, CVSS-BT with threat, CVSS-BTE with threat and environment. The intent is transparent. FIRST would like everyone to stop steering by CVSS-B.

In practice, almost nobody fills in the other two groups, because doing so means knowing your estate and following the news on every CVE. So teams steer by the base score, which is a theoretical severity rating, identical for every company on the planet.

KEV: what is being exploited, with evidence

The KEV catalog (Known Exploited Vulnerabilities) has been run by CISA, the US cybersecurity agency, since November 2021. It comes with a directive (BOD 22-01) requiring federal civilian agencies to remediate each entry by a due date, generally two to three weeks after it is added.

To enter the catalog, a vulnerability must meet three conditions: have a CVE identifier, be backed by reliable evidence of active exploitation, and have a clear remediation action (a patch, a workaround, or removing the product). The catalog holds more than 1,500 entries today. Against the hundreds of thousands of CVEs in existence, that is tiny, and that is the whole point.

Two things make it directly usable. It is published as JSON and CSV, with no key and no sign-up. And every entry carries a knownRansomwareCampaignUse field, which flags the flaws seen in ransomware campaigns. For a small or mid-sized business, that is probably the most telling field in the entire ecosystem.

Now the limits. KEV is a binary, late signal: a flaw gets in once exploitation is established, so after the first victims. It also reflects its author's priorities. Products that are widespread in US government are better covered than a French CMS or an industry-specific ERP. A CVE missing from the catalog proves nothing. Its presence, on the other hand, ends the debate: if it is in KEV and it is on your network, whether to fix it is no longer the question.

EPSS: the probability that it happens

EPSS (Exploit Prediction Scoring System) is FIRST's other project, more recent and far less known in boardrooms. It is a statistical model, recomputed every day for every published CVE, that estimates the probability of exploitation activity being observed in the next 30 days. The model is on its fourth version, released in March 2025.

Each CVE gets two values, and they should not be mixed up:

• the probability, between 0 and 1. An EPSS of 0.42 means a 42% chance of seeing exploitation within the month;
• the percentile, which ranks the CVE against the others. A percentile of 0.95 means 95% of CVEs score lower.

The distribution is heavily skewed: the overwhelming majority of CVEs score close to zero. A probability of 0.1 looks low in absolute terms. It still puts the vulnerability in the top few percent of the ranking.

The argument that convinced us is in the research paper that came with version 3 of the model (Jacobs et al., 2023). The authors compare two strategies on the same data. Fixing everything with a CVSS base score of 7 or more covers 82% of the vulnerabilities that actually got exploited, at the cost of an effort spanning 58% of all CVEs. Reaching the same coverage with EPSS (threshold at 0.088) means handling 7.3% of CVEs. Eight times less work for the same result.

The score still has to be read for what it says. EPSS estimates the probability that the project's data partners observe exploitation with their sensors. Quiet, targeted exploitation that trips no network signature will be under-represented. A CVE published yesterday will score low simply because the model has no signal yet: that is no clean bill of health. And EPSS says nothing about impact. FIRST repeats it in its FAQ, the score ignores your context and your compensating controls.

What none of the three knows: your exposure

CVSS describes the flaw. KEV and EPSS describe what attackers do with it. None of them describes you.

Yet the variable that weighs most in a triage is local: can the vulnerable component be reached, and by whom? A remote code execution rated 9.8 on an internal tool used by twelve people behind a VPN is a real issue, to be handled in the normal cycle. The same one on a service answering the whole planet is an emergency, because mass scanners will have found it before the day is out.

That assumes you know what you expose, and this is where most prioritization efforts get stuck. You cannot tag an asset "exposed" if you do not know it exists. The pre-production subdomain a contractor set up three years ago is in no CMDB, so in no triage. We detailed how to build that inventory in our article on mapping your information system. It is the prerequisite for everything that follows.

The triage rule we apply

Here is the order in which we ask the questions. There is nothing original about it, it closely resembles what CISA formalizes in its SSVC decision tree. Its merit is that it fits on half a page and can be applied by someone who was not in the meeting where it was decided.

Three remarks on this table.

The delays are ours, not a standard. A two-person team can legitimately write 5 days at rank 1. What matters is that the number is written down, met and measured.

The EPSS threshold of 0.1 is a starting point. If it surfaces too many lines for your capacity, raise it. If it surfaces almost none, lower it. A threshold gets tuned to what you can really handle, not to what feels reassuring.

And rank 5 is not a dustbin. "Normal cycle" assumes there is a normal cycle, meaning regular updates that sweep up the long tail without anyone reviewing it line by line. Without that cycle, rank 5 swells until it supplies next year's rank 1s.

Example: five lines from the same report

Take a fictional but realistic report, sorted the way the tool outputs it, by descending CVSS.

With a CVSS sort, the team starts with A and B. Two flaws that are serious on paper, that nobody exploits, and that only an attacker already inside could reach.

With the rule above, the order becomes D, C, E, then A and B. The VPN gateway goes first despite its 7.5: it is exposed, actively exploited, and a textbook ransomware entry point. The CI server follows. And line E, which a CVSS sort would have left asleep for a year with its 5.3, moves up to third place. An exposed information leak that attackers are already probing often serves as the first step toward something else.

A and B do not vanish. They wait until the following week, which is very different from never being handled.

Getting the data without buying anything

Both sources are public and free. To query EPSS for a CVE:

curl -s "https://api.first.org/data/v1/epss?cve=CVE-2021-44228" \
  | jq '.data[0] | {cve, epss, percentile}'

To check whether a CVE is in the KEV catalog, with its due date and the ransomware flag:

curl -s https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json \
  | jq -r '.vulnerabilities[]
      | select(.cveID == "CVE-2021-44228")
      | [.cveID, .dateAdded, .dueDate, .knownRansomwareCampaignUse] | @tsv'

On Log4Shell, the first command returns a probability pinned at 1 and the second an entry dated December 10, 2021. No surprise there, but it lets you check the plumbing works before wiring it to a scanner export.

Because that is the next step: a loop over the CVE list from your latest report, a join with your inventory for the "exposed" column, and the sort takes care of itself. Half a day of scripting for someone comfortable with it, and most scanners on the market now offer these columns natively. If yours does not, we listed the selection criteria in which vulnerability scan to use.

The traps we run into

Believing a low EPSS means "safe". The score is a 30-day probability, at global scale. A flaw at 0.03 on a niche product with three users in your country may well be the one a targeted attacker picks. EPSS is for ordering a queue, not for closing tickets.

Forgetting that scores move. An EPSS can go from 0.02 to 0.8 in a week when an exploit is released. A triage done on scan day and never refreshed is wrong within a month. The recalculation has to be automatic, or it will not happen.

Depending on a single source. Since February 2024, the NVD has built up a significant backlog in CVE analysis, and many recent entries have neither a score nor an affected-products list on the NIST side. CISA partly makes up for it with its Vulnrichment project. In April 2025, funding for the CVE program itself came within hours of lapsing. ENISA opened its own European database, the EUVD, the following month. The lesson for a CISO: do not build your prioritization chain on a single source, and check what your tool does when the NVD has nothing to say.

Taking the vendor's CVSS for the NVD's, or the other way round. The two regularly diverge, sometimes by several points. The vendor knows its product better, but also has an interest in not displaying a 9.8. When they differ, keep the higher one for sorting, and read the vector rather than the number.

Sorting without ever measuring. A prioritization rule with no metric ends up as a poster in a corridor. Two numbers are enough: median time to fix per rank, and the count of rank 1 and 2 lines open past their delay. If the second is not zero, that is the topic of the next meeting.

Where does compliance fit in?

Good news, the frameworks point the same way. Control A.8.8 of ISO 27001

In both cases, what an auditor wants to see is not a backlog at zero, which they know is impossible. It is a written rule, evidence that it is followed, and an explanation for each exception. A five-rank table, measured delays and a list of signed-off exceptions are worth more in an audit than a policy that promises to fix every critical within 30 days and that the numbers contradict. We described what that evidence looks like in the NIS2 compliance report guide.

What we do with this at Flawfence

Let us say where we stand. Flawfence continuously monitors its customers' external surface, which by design puts us on ranks 1, 2 and 4 of the table: what is exposed. Our bias is that the "exposed" column should not be declared by the customer but observed from the outside, because the forgotten asset is precisely the one nobody would have ticked. And we try to validate that a flaw is really exploitable before reporting it, which removes a good share of a classic scanner's noise from the triage.

What we do not do: your internal estate, your workstations, your Active Directory. The triage rule applies there just the same, with other tools.

FAQ

Should we drop CVSS?

No. CVSS remains the best available description of how severe a flaw is, and its vector (network or local access, privileges required, user interaction) is a goldmine. What should be dropped is its use as the sole sorting criterion. It keeps its place at rank 4 of our table: at equal exposure and with no exploitation signal, the more severe goes first.

Which EPSS threshold should we pick?

Start at 0.1 and adjust to your remediation capacity. The work published with EPSS v3 shows that a threshold near 0.09 covers as many exploited vulnerabilities as a "CVSS ≥ 7" sort, for roughly eight times fewer fixes. If your team can absorb more, lowering the threshold increases coverage.

The KEV catalog is American. Is it relevant for a European company?

Yes, with one caveat. Opportunistic attackers do not look at borders, and the edge devices, VPNs, mail servers and hypervisors listed in KEV are the same on both sides of the Atlantic. The caveat concerns very local products, which are less well covered. Complement it with your national CERT's alerts and advisories (CERT-FR in France), which also flag active exploitation.

What about a vulnerability with no score at all?

That is increasingly common since the NVD fell behind. Look at the score from the vendor or the authority that assigned the CVE, CISA's Vulnrichment data, and the EUVD record. Failing all that, go back to the two questions that depend on no database: is the component exposed, and is there a public exploit?

How often should the triage be redone?

EPSS scores change every day and KEV grows several times a week. An automated weekly recalculation is a reasonable minimum. For Internet-facing assets, a daily check makes sense: the gap between a patch being released and the first mass exploitation is now counted in days.

Conclusion

CVSS says whether it is severe, KEV says whether it is exploited, EPSS says whether it probably will be. None says whether it is reachable on your side, and yet that answer is what reorders everything else.

If you do only one thing this week, take your latest scan report, add two columns (KEV, exposed), and see what rises to the top. Chances are it will not be a "critical".