CVE monitoring that leads to action.

Updated on 27 October 2026

A CVE (Common Vulnerabilities and Exposures) is the public identifier of a vulnerability. More than 40,000 were published in 2024, and the curve hasn’t flattened since 2016 (CVE program metrics). A team running around thirty components will see a few dozen over the year that actually concern it. The whole problem lies in that ratio.

The real cost of noise

Reading every published CVE would take more than two hours per working day, for a relevance rate below one percent. Nobody keeps up that pace. What happens in practice is worse than giving up: the team reads for two weeks, then skims, then filters on “critical”, then stops opening it. The day a flaw really does concern them, the notification lands in a channel nobody looks at anymore.

So the real risk is tuning out, not volume. A monitoring setup is judged on one question: will anyone still be reading it in six months?

Building a scope, and keeping it current

A monitoring scope is the list of what you run, with versions. There are three ways to build it: enter it by hand, import an SBOM (Software Bill of Materials, the component inventory produced by your software build pipeline), or let the technologies behind a public URL be detected. Allow two minutes for about ten components.

The hard part is not creating it, it’s keeping it current. A version upgrade, an added library, a server taken over from a client: every unrecorded change is a blind spot. Importing an SBOM with every release is the only mechanism that holds up over time, because it doesn’t depend on anyone’s memory.

Three signals for prioritizing, and when each one gets it wrong

Once the list is narrowed down, you still have to choose the order. Three public references answer that, and they should be read in this exact order.

KEV first: the catalog of actively exploited vulnerabilities, published by the US cybersecurity agency. It’s not a forecast, it’s an observation: the list of fires already burning. A CVE that is in the KEV and present in your environment gets fixed, no discussion. Its limitation: it only lists what has been observed and reported, so it sometimes arrives after exploitation. How to read the KEV catalog.

EPSS next: a probability of exploitation being observed within the next thirty days, recalculated every morning. It’s the weather forecast: you don’t argue with a chance of rain, you take an umbrella. Its limitation: it describes the world, not you. A high-probability flaw in a service you don’t expose hardly concerns you. What EPSS predicts, and what it doesn’t.

CVSS last: the intrinsic severity, from 0 to 10. It’s the magnitude of an earthquake: the strength of the event, regardless of whether there is a city above it. Its limitation is the most important one to know: most CVEs rated critical are never exploited. How to read a CVSS vector, and the calculator to build one.

A rule you can use as is: anything in the KEV and present in your environment gets handled within 48 hours; next, anything with an EPSS above 0.1; CVSS only serves to break a tie between two candidates.

What happens after the alert

An alert that leads nowhere is a cost with no return. The full path has four states: received, analyzed, being fixed, resolved. Every alert has a named owner; each change of state leaves a dated record, which is as useful to the team as it is to an auditor six months later.

Two delays not to be confused, because they get mixed up everywhere. The synchronization: how often the feeds are re-read. The processing: the time between reading a CVE and the notification, which with us follows the reading immediately, with no batch processing. No tool can be faster than its synchronization frequency, and any vendor who announces a single figure is hiding another.

End of support, the blind spot

An end-of-life version will never receive another patch. It’s not one more vulnerability: it’s the guarantee that every future one will stay open. Serious monitoring therefore tracks end-of-support dates as closely as CVEs, with enough notice to plan a migration rather than discover it on the day.

19 sources, cross-checked

No single source is complete on its own. Since February 2024, CVE enrichment by the NVD had slowed down sharply; since April 2026, NIST no longer enriches most CVEs, which stay without a score or product reference. We cross-check 19 sources, including nine vulnerability feeds: the CVE list, the NVD, the KEV catalog, EPSS scores, published proofs of concept, GitHub advisories, OSV, CERT-FR publications and the European EUVD database, so we stay usable when one of them falls behind. Sources and their licenses in detail.

In practice, on Monday morning

Four steps, in this order, for a team starting from nothing.

1. Declare twenty components, versions included. Not a hundred: the ones exposed to the Internet and the ones holding data.
2. Set the threshold. Everything in the KEV, whatever its score, plus anything above 7 in CVSS. That takes you from several thousand CVEs a month down to a handful of alerts.
3. Separate the channels. Critical items to Slack or Teams, the rest in a daily digest. Sending everything to Slack is the same as muting Slack.
4. Review the volume after one week. More than ten alerts? Raise the threshold. Zero? Your scope is probably incomplete.

Which tool to handle all this

The method above doesn’t depend on any product. To choose the one that carries it out, two pages: the 2026 ranking of six CVE monitoring tools if you’re starting from scratch, and the head-to-head comparisons if you already use Tenable, Qualys, Action1, Intruder, Cyberwatch, OpenCVE or CVEDetails. TechWatchAlert applies this method all the way to the patch and the NIS2 evidence, in seven languages, hosted in France, with a free plan and a no-account tool to put it to the test on your own scope.