New critical vulnerabilities — how not to drown in CVEs

More than twenty thousand new vulnerabilities are added to the CVE database every year. No team can respond to all of them. The problem for an average organisation is not a lack of information about flaws, but the lack of a way to separate the important ones from the media noise. Below is how we approach prioritisation when working with clients.

A CVSS score alone is not enough

The CVSS rating is useful, but it only describes a vulnerability’s theoretical severity in isolation from context. A flaw scoring 9.8 in a component you don’t use, or that isn’t reachable from the network, matters less to you than one scoring 6.5 in a publicly exposed service handling customer data.

Instead of treating CVSS as the only criterion, we combine it with three questions:

• Is the component used here, and in which version? Without an up-to-date asset inventory, the answer is a guess.
• Is the vulnerable element reachable by an attacker? A flaw in a service behind a VPN with no exposure is a different risk from the same flaw on the front end.
• Is there a public exploit, and is it being actively used? This is often more important than the numeric score itself.

Active exploitation changes everything

The single best signal of priority is the news that a vulnerability is already being used in attacks. The US agency CISA maintains the KEV (Known Exploited Vulnerabilities) catalogue, and many threat intelligence vendors publish similar data. If a flaw lands in KEV, treat it as urgent regardless of its CVSS score. KEV pairs well with EPSS (Exploit Prediction Scoring System), which scores the probability that a given flaw will be exploited. Combining KEV, EPSS and your own environment’s context beats prioritising by CVSS alone.

In practice this means a simple mechanism: a daily comparison of your component list against the catalogue of actively exploited vulnerabilities. This task can be fully automated and is one of the cheapest security investments you can make.

Inventory as the foundation

Every conversation about vulnerabilities ends in the same place: you cannot protect assets you don’t know exist. A forgotten test server, an old application instance, or a library pulled in as a transitive dependency — these are typical entry points.

The minimum set to start with:

• An up-to-date list of internet-facing services (an external attack-surface scan).
• A list of dependencies in applications with their versions (an SBOM — Software Bill of Materials).
• A register of operating systems and their patch levels.

The time window matters

From the publication of a vulnerability to the appearance of a mass-exploited exploit can take a few days — and sometimes a few hours. That is why prioritisation must go hand in hand with a ready patching process: defined maintenance windows, a fast-track path for critical flaws and clearly assigned responsibility.

If an immediate update is not possible, you apply compensating controls: restricting network access, WAF rules or disabling the vulnerable function until the patch is applied.

Summary

Effective vulnerability management is not a race after every new CVE, but a repeatable process: complete inventory, combining severity with exposure context, priority for actively exploited flaws and a ready mechanism for fast patching. If you’d like to check which of the published vulnerabilities actually affect your infrastructure, get in touch — we’ll help set up the process from scratch.