KEV before CVSS: why your patch order is usually wrong

Most teams sort vulnerabilities by a single number: CVSS. Nines and tens first, then the rest. It is the default, it is convenient, and it is usually wrong. Not because CVSS is bad, but because it answers a different question from the one you actually care about.

CVSS tells you how dangerous a vulnerability is in theory, if someone were to exploit it. What you care about is what an attacker will actually walk in through this week. Those are not the same question, and the gap between them decides whether you spend your time on the right things.

A short example of the point

Picture a fleet with four hundred critical vulnerabilities, CVSS 9 and above. The team throws itself at them because they are red and high. At the same time one medium vulnerability, CVSS 5.4, has confirmed active exploitation. That does not establish that a public exploit is available. It does establish that the risk is no longer merely theoretical.

This is not a theoretical scenario. It is the most common way a well-working team loses: doing plenty of work in the wrong order.

What KEV is

CISA maintains a catalogue called Known Exploited Vulnerabilities, KEV for short. It is a list of vulnerabilities for which exploitation in real attacks has been confirmed. Not "could exist", not "is theoretically possible", but confirmed that someone is using this against someone.

That changes the nature of the information. CVSS is an expert assessment from a model. KEV is an observation from the field. A vulnerability in KEV is not a risk forecast, it is the fact that the risk has already materialised for others. That is why it deserves different treatment from a vulnerability with a high CVSS but no known exploit.

What EPSS is

The second tool is EPSS, the Exploit Prediction Scoring System. It is a model that estimates, for a given vulnerability, the probability that it will be exploited within the next 30 days. Unlike KEV, which is binary (there is an exploit in use or there is not), EPSS gives a continuous value, a forecast.

EPSS is useful for ordering what is not yet in KEV. A vulnerability with a high EPSS is a candidate that could land in KEV tomorrow. I treat it as an early warning, not a verdict.

A sensible ranking

The order I use, and consider reasonable for most fleets, looks like this:

KEV first. If a vulnerability is in the catalogue of known exploited ones, it goes to the front, even if its CVSS is low. An actively used exploit beats theoretical severity. This is the heart of the whole approach and the single change that gives the biggest effect.

Then severity, meaning CVSS. Among vulnerabilities with the same KEV status, the more dangerous ones rank higher. CVSS does not vanish from the puzzle, it drops to a second dimension.

Then the deadline. A vulnerability whose SLA is near or overdue jumps ahead of one that still has time to spare. The process should police its own deadlines.

Then machine context. System criticality and network exposure separate what the earlier dimensions left tied. The same vulnerability on an internet-facing server is more urgent than on an isolated internal machine.

The result is that a low vulnerability with an active exploit lands ahead of a hundred high ones without an exploit, and that is exactly the order an attacker wants to work in, so you should too.

Where this approach has limits

I would be dishonest if I sold KEV as a silver bullet. It has two real limitations.

KEV is reactive and incomplete. A vulnerability enters the catalogue once exploitation is observed and confirmed, which by definition is after the fact. A fresh, targeted attack may use something not yet in KEV. That is why CVSS and EPSS stay in the mix as the remaining dimensions rather than disappearing.

With few findings, the order matters less. If you have five open vulnerabilities, just fix all of them and skip the philosophy. Ranking starts to matter when findings number in the hundreds and you physically cannot do everything at once. Then the order is the difference between being safe and being busy.

In practice

Manually ordering hundreds of vulnerabilities by several dimensions is not feasible, so this is precisely the part worth automating. The Secvalis queue puts KEV first, then considers severity, overdue status, asset criticality and exposure, and finding age. EPSS is an additional predictive signal, but it would be inaccurate to present it as a separate sorting key today. To see the queue on a sample fleet, enter the demo.

Fixing vulnerabilities in order of descending CVSS looks tidy and gives a sense of progress. The trouble is that the attacker does not read your list from the top. They come in where they have a working exploit, and your order should reflect that before they use it.

Sources

• CISA: Known Exploited Vulnerabilities Catalog
• FIRST: Exploit Prediction Scoring System