What is a CVE?

Two images to make it concrete

First, a CVE is a license plate. It designates one specific vehicle, and only one. It doesn't tell you how fast it's going, whether it's moving at all, or whether it has already crossed your path. Two witnesses who cite the same plate are necessarily talking about the same vehicle: that's all it guarantees, and that's already a lot.

Second, a CVE is an ER case number. You get it at admission, before any diagnosis: the number exists while the file is still empty. That is exactly the “reserved” state of a CVE, and it's why a CVE can show up in a tool with almost no information — then fill in over the following days.

Remember the question a CVE answers: which flaw are we talking about? — not “is it serious?”, not “am I under attack?”

Anatomy of an identifier: CVE-YYYY-NNNN

A CVE identifier always follows the same structure:

Two subtleties almost everyone misses:

• The year reflects the reservation of the identifier, not its publication. A CVE reserved in December 2025 and disclosed in March 2026 keeps the year 2025. So sorting a feed by year has nothing to do with sorting by recency.
• The sequence number has at least four digits and can grow longer. We have gone from CVE-2014-0160 to six-digit identifiers to absorb the volume: an alphabetical sort breaks where a numeric sort holds.

Who assigns CVEs: the role of CNAs

No central authority assigns identifiers. That job belongs to authorized organizations called CNA (CVE Numbering Authorities), which reserve and publish them within their own scope. The program counts more than 400 worldwide; the official list, the only up-to-date one, is published by cve.org.

• The vendors (Microsoft, Apple, Google, Red Hat, Cisco…) are their own CNA and publish the CVEs for their products.
• There are also coordinators — CERT/CC, national CERTs — that cover software with no vendor CNA, especially open source.
• The MITRE is the program's root CNA and secretariat; CISA, the US cybersecurity agency, funds it.

This decentralized model provides coverage and speed: whoever knows the flaw best documents it. It comes at a cost, which is the subject of the next section.

What a CVE record contains, and what's often missing

A published CVE provides, at a minimum:

• a description of the vulnerability;
• the affected products and versions, ideally as a standardized identifier, CPE (Common Platform Enumeration, the naming scheme that describes software in a machine-readable way);
• the weakness behind it, classified using CWE;
• a severity score based on CVSS, not always available at publication;
• and references: security advisories, patches, proofs of concept.

How complete these fields are depends entirely on the CNA that publishes the record. Since February 2024, enrichment by the NVD (scores and CPEs added after the fact) has slowed sharply, leaving a large number of records without usable affected-version data. A CVE with neither a CPE nor a version range cannot be matched against any inventory, by any tool: it is invisible to automated correlation. That is the practical reason why cross-checking several data sources has become essential, and why the quality of a CNA is worth measuring.

The lifecycle of a CVE

A CVE is not set in stone. Its status changes, and those changes often matter more than its initial publication.

On top of these states come two transitions that change everything for prioritization: being added to the CISA KEV catalog, which means exploitation has been observed, and the appearance of a proof of concept (PoC, in short: published code that demonstrates the attack), which puts exploitation within anyone's reach. Monitoring that only tracks new publications misses both.

CVE, CVSS, EPSS, KEV: don't mix them up

This is the most common confusion, and it costs a lot of time. A CVE identifies; the other three characterize the same flaw from different angles.

One flaw seen through all four frameworks

Let's take Log4Shell and follow it from one framework to the next. This exercise makes the difference clearer than any definition.

Read the last row: between publication and confirmed exploitation, only a few hours went by. For a flaw with this profile, the window between “we find out” and “we're under attack” is not measured in weeks. That is something the CVSS score alone would never have told you.

Three CVEs that made history

Heartbleed — CVE-2014-0160 (April 2014)

An OpenSSL flaw that let attackers read a server's memory: private keys, passwords, session contents. A telling detail: its CVSS 3.1 score is 7.5, “high,” not “critical” — because it only allows reading, without modifying or disrupting anything. Yet it led to the reissuing of a massive share of the web's certificates. Proof that the score does not measure reach.

Log4Shell — CVE-2021-44228 (December 2021)

Remote code execution in Log4j, the logging library found in a huge share of enterprise Java software. Rated 10 out of 10, exploited en masse within hours of disclosure. Its lasting lesson: most affected organizations didn't know they were using Log4j, because it came in as a dependency of a dependency.

XZ Utils backdoor — CVE-2024-3094 (March 2024)

A backdoor deliberately planted in a Linux compression tool, the result of two years of patience by a contributor who became a maintainer. Spotted by chance by a developer who noticed an abnormally slow SSH connection, a few weeks before the package reached stable distributions. Rated 10 out of 10. It shifted the question from “is my code safe?” to “who does my code trust?”

Why CVE volume is exploding

The numbers for the most recent full years: more than 40,000 CVEs published in 2024, about 28,800 in 2023, 25,000 in 2022. The curve has not dipped a single year since 2016. More software, more researchers, more authorized CNAs: all three factors push in the same direction.

Let's convert that into working time. Forty thousand CVEs spread over about 250 working days comes to 160 records a day. At forty-five seconds to read a record and decide whether it concerns you, that takes two hours per working day — for a relevance rate that, for an SMB environment, falls well below one percent. No team can keep up that pace, and none should have to.

The program's official counter, updated continuously, is published at cve.org/about/Metrics. We would rather point you there than freeze a figure here that will be outdated in six months.

What it means for you, in practice

Here is what a team that has stopped drowning in the feed does on Monday morning.

1. Write down the inventory. Vendor, product, major version, for everything that is exposed or holds data. Twenty to forty lines are enough for an SMB. Without this list, no filtering is possible: it is the only work you truly cannot skip.
2. Filter against that list. Anything that doesn't match a line of the inventory is out of scope. That's where 99% of the noise disappears.
3. Sort what's left, in this order. In the KEV → handle within 48 hours. Otherwise, EPSS above 0.1 → this week. Otherwise, CVSS breaks the tie, and only then.
4. Watch the transitions. A CVE rated “low” on Tuesday can enter the KEV on Thursday. What should trigger an alert is not just publication, it's a change of status.

FAQ