What the vulnerability record actually says

Why we did this

Almost every security standard tells businesses to patch by severity: fix anything scored 7 or above, usually within 14 days. It is written into Cyber Essentials, it is how most tools sort their queues, and for a business without a security team it produces a list far longer than anyone can work through.

So we asked a question the standards do not answer. If you can only act on some vulnerabilities, which ones actually matter? Not which score highest, but which turn out to be used against real businesses.

How we did it

The analysis covers 248,176 public vulnerability records. The sources are public: the National Vulnerability Database, CISA's Known Exploited Vulnerabilities catalogue, GitHub Security Advisories, and the Exploit Prediction Scoring System. Exploitation is measured against CISA's catalogue, which records flaws confirmed as being used in the wild.

Three limits are worth stating plainly, because they shape everything below.

First, CISA's catalogue is a floor rather than a census. It records what one agency has confirmed and chosen to publish, mainly to drive remediation across US federal government. Plenty of real exploitation never reaches it, so every figure here understates rather than overstates.

Second, the severity scores we analysed are current ones, not the score a flaw carried on the day it was published. Scores get revised upwards once exploitation becomes known, so where we report that exploited flaws were scored low, the true figure at the time a defender had to decide is higher than what we can show.

Third, the record itself is incomplete. Roughly a third of it carries no severity score at all, and around 28% cannot be reliably matched to a product. Those gaps are findings in their own right, and they cap how far any product-level analysis can go.

The data was gathered using StackFlag, which is a Steelwise product. The underlying vulnerability data is public and third-party. We have published the caveats that weaken our findings alongside the findings themselves, including two defects in the collection that we found while doing this and had to correct before the analysis stood up.

What we found

• Sorting by severity is expensive and imprecise. Patching everything scored 7 or above means working through 89,697 items to catch 81% of exploited flaws. A probability-based rule catches 72% from a list of 3,513. That is 25 times the workload for nine and a half percentage points.
• "Just do the criticals" is the worst rule we tested. It catches under a third of what gets exploited, and still leaves 20,491 things to do.
• 97% of critical-scored vulnerabilities are never exploited by anyone. Of 20,491 flaws scored 9.0 or higher, 570 show any exploitation evidence.
• The mismatch runs both ways. Close to one in eight confirmed-exploited flaws was scored below 7, and a further 141 carried no score at all, so a threshold filter drops them silently.
• The typical exploited flaw is nine months old. Median time from publication to confirmed exploitation is 272 days, and 46.9% take more than a year. Watching only new vulnerabilities misses most of what matters.
• Counting flaws per product is close to useless as a risk signal. The Linux kernel has 8,053 recorded vulnerabilities and under 1% exploited. FortiOS has 113 and nearly one in five.

The filings, in reading order

These were published as four separate filings. They are best read in this order rather than by date.

1. The patching rule that beats "just do the criticals". Start here: which selection rule actually catches exploited vulnerabilities, and what the alternative costs.
2. 97% of critical vulnerabilities are never exploited by anyone. What a severity score measures, what it misses, and which parts of it carry real signal.
3. The vulnerability that gets you is nine months old. The gap between publication and exploitation, and why the backlog matters more than the inbox.
4. Counting vulnerabilities tells you almost nothing about risk. Why flaw counts mislead, and what to look at instead.

If you are deciding what to patch

The short version: meet whatever standard you are certifying against, then use exploitation probability to decide what order to work through it in. The first filing sets out the numbers behind that, and the third explains why the old items on your list deserve more attention than they usually get.

Questions about this research

If you are a journalist, researcher, or practitioner and want to discuss the method or the findings, email [email protected]. If you are a business trying to work out what to patch, the contact page is the place to start.