Stop patching by severity and start patching by evidence

Every vulnerability management programme we have reviewed starts the same way. Sort by CVSS, work down from the nines, report the number remaining. It is defensible, it is easy to explain to a board, and it quietly wastes an enormous amount of effort.

The problem is not that CVSS is wrong. It is that it answers a question you were not asking.

What the score actually tells you

A CVSS score is a description of how severe a vulnerability would be if somebody exploited it, assessed in the abstract, without any knowledge of your environment. It is a property of the flaw.

What a defender needs is different. You need to know whether this is being used, against organisations like yours, on systems you actually expose. That is a property of the world, and of your estate. The score cannot carry that information, and it was never designed to.

The result is familiar. A team spends a fortnight on a critical rated flaw in an internal tool that three people use and cannot be reached from outside, while a medium rated issue on an internet facing gateway sits in the backlog, being actively exploited somewhere else that week.

Three signals worth more than the score

Is it being exploited. The CISA Known Exploited Vulnerabilities catalogue is a list of flaws with confirmed evidence of exploitation in the wild. If something you run appears on it, the theoretical discussion is over. That is not a risk assessment any more, it is a race.

How likely is exploitation. EPSS, maintained by FIRST, scores the probability that a vulnerability will be exploited in the near term. It disagrees with CVSS constantly, and when it does, it is usually the more useful of the two for deciding what to do on Monday.

What is actually exposed. This one nobody can give you. It comes from your own asset picture. The same flaw on a public gateway and on an isolated lab host are not the same problem, and any prioritisation that treats them identically is guessing.

A known exploited flaw on an internet facing service is not a high severity finding. It is an incident that has not started yet.

Putting them together

The order that tends to survive contact with a real backlog looks like this.

1. Known exploited, and exposed to the internet. Everything else waits.
2. Known exploited, internal only. Fast, but planned rather than panicked.
3. High exploitation likelihood on exposed systems, whatever the severity rating says.
4. Everything else, worked by severity, on a normal cycle.

Notice that severity only appears at step four. That is not because it does not matter. It is because by the time you get there, the items that could genuinely hurt you this month have already been dealt with.

The National Vulnerability Database remains the right place to get the underlying detail once you have decided something matters. The point is that it should not be the thing that decides.

The conversation this changes upstairs

There is a reporting benefit here that is worth more than the operational one.

"We have four hundred and twelve outstanding criticals" is a number that generates anxiety and no decisions. It has been true for years, it will be true next year, and everybody in the room has learned to ignore it.

"We have three known exploited vulnerabilities on internet facing systems, two are patched, the third needs a maintenance window on Thursday" is a sentence that produces a decision. It is also honest, specific, and small enough that somebody will remember it next week.

That shift, from volume to evidence, is most of what separates a vulnerability programme that drives action from one that produces a monthly report nobody reads.

Where this connects to the rest

Knowing what is being exploited is only half of it. The other half is knowing which of your controls was supposed to cover it, and whether anybody has confirmed that control recently. That is the join we keep coming back to, and it is why Threat Intelligence Mapper ends its output at a check rather than a warning, and why threat informed prioritisation sits on the CyberNexus direction of travel rather than in a separate tool.

MITRE ATT&CK is the common language for the middle of that, mapping what an attacker does to what you are supposed to have in the way.

Start here

You do not need a new platform to change this. You need one afternoon.

Take your current patching queue and cross reference the top of it against the KEV catalogue. If nothing at the top of your list appears, and something further down does, you have just learned something important about how your programme is currently ordered, and you have learned it cheaply.

Common questions

Should we patch by CVSS score

Not as the primary signal. CVSS describes how severe a flaw would be in the abstract, without any knowledge of your environment. What a defender needs is whether it is being exploited, how likely exploitation is, and whether the affected system is actually exposed.

What is the CISA KEV catalogue

A published list of vulnerabilities with confirmed evidence of exploitation in the wild. If something you run appears on it, the theoretical risk discussion is over and the item belongs at the top of the queue.

What is EPSS and how is it different from CVSS

EPSS scores the probability that a vulnerability will be exploited in the near term. CVSS scores how bad it would be if somebody did. They disagree frequently, and when they do, EPSS is usually the more useful of the two for deciding what to do on Monday.

How should we order a patching backlog

Known exploited and internet facing first, then known exploited internally, then high exploitation likelihood on exposed systems, then everything else by severity on a normal cycle. Severity appearing fourth is the point.