The CVE system exists to solve a coordination problem that once made vulnerability management nearly impossible. Before it, two vendors could describe the same flaw in completely different words, so a defender had no reliable way to know whether two advisories referred to one vulnerability or two. A CVE fixes this by giving each known vulnerability a single, unambiguous name that everyone uses, from researchers to vendors to the tools that scan your network. This guide explains how the system works, how a CVE moves through its lifecycle, how it differs from the scores and catalogs it is often confused with, and how to actually use CVEs in a security program.
How the CVE system works
A CVE identifier is assigned by a CNA (CVE Numbering Authority), an organization authorized by the CVE Program to allocate IDs within its scope. Many large technology vendors are CNAs for their own products, which lets them assign a CVE the moment they confirm a vulnerability. MITRE operates the program and acts as the top-level coordinator, while CISA sponsors it. This federated structure is what allows the system to scale to tens of thousands of new CVEs each year.
It is worth being precise about what a CVE is and is not. A CVE is an identifier and a short description. It is not a severity score, not a database of exploit details, and not a fix. Those functions belong to other systems that build on top of the CVE, described below.
The anatomy of a CVE identifier
The format is deliberately simple so that a human or a machine can parse it instantly:
| Part | Meaning |
|---|---|
| CVE | The fixed prefix identifying the standard |
| YYYY | The year the ID was reserved or assigned |
| NNNNN | A unique sequence number, variable in length |
An identifier such as CVE-2021-44228 points to exactly one vulnerability, and anyone in the world can look it up and know precisely which flaw is meant. That universality is the entire value of the system.
The CVE lifecycle
A CVE record moves through defined states, and knowing them helps a team interpret what a given identifier actually tells them at a moment in time.
First, an ID can be reserved by a CNA, which means the number is allocated but the details are not yet public, often during coordinated disclosure while a fix is being prepared. Next, the CVE is published, meaning the description and references become public. Finally, the record is enriched in the National Vulnerability Database, where analysts add severity scoring and additional metadata. A newly published CVE may therefore exist for a short time before it has a full severity analysis attached, which is a nuance that matters when you are triaging something brand new.
The National Vulnerability Database and enrichment
The National Vulnerability Database (NVD), run by NIST, is built on top of the CVE list and is where most defenders actually consume CVE data. The NVD takes each published CVE and adds analysis, most importantly a CVSS severity score, references, and product information expressed in a structured format that scanners can match against your assets. In practice, when a vulnerability scanner tells you that a server is affected by a specific vulnerability, it is matching your software against enriched CVE records from the NVD. Any backlog or delay in that enrichment can leave freshly published CVEs without a score for a period, which is another reason mature teams do not rely on a single signal.
CVE, CVSS, CWE, EPSS, and KEV: how they fit together
This family of acronyms is the most common source of confusion, and understanding how they relate is what separates a superficial grasp from real fluency. Each answers a different question:
| Standard | Question it answers | Maintained by |
|---|---|---|
| CVE | Which specific vulnerability is it? | MITRE / CNAs |
| CWE | What type of weakness is it? | MITRE |
| CVSS | How severe is it, in the abstract? | FIRST, scored in the NVD |
| EPSS | How likely is it to be exploited soon? | FIRST |
| CISA KEV | Is it being actively exploited right now? | CISA |
Read as a sentence: a CVE is a specific instance of a CWE weakness type, rated for severity by CVSS, with a real-world exploitation probability from EPSS, and flagged by the CISA KEV catalog if attackers are using it now. A team that understands this stack prioritizes far better than one that reacts to CVSS scores alone.
The CISA KEV catalog: prioritizing what matters
Of all the signals above, the CISA Known Exploited Vulnerabilities catalog deserves special attention, because it answers the question that matters most operationally: which of the thousands of open CVEs are attackers actually exploiting today. A vulnerability being in the KEV catalog is a strong signal to patch it urgently, regardless of its CVSS score, because it moves the flaw from theoretical to confirmed active abuse. Many organizations now build their patch priorities around KEV first, then EPSS and CVSS, precisely because it focuses limited remediation capacity on real threats.
How to use CVEs in vulnerability management
For a security team, CVEs are the connective tissue of the entire vulnerability management program. The practical workflow looks like this:
- Identify which CVEs affect your environment, by matching an accurate asset inventory against scanner output drawn from the NVD.
- Prioritize using multiple signals rather than one. Start with the CISA KEV catalog for anything under active exploitation, then weigh EPSS probability and CVSS severity against the business value of the affected asset.
- Remediate by patching, reconfiguring, or applying a compensating control, then confirm the fix worked.
- Track your exposure over time, measuring how quickly you close the highest-risk CVEs rather than trying to close every one.
The mark of maturity is not a CVE count of zero, which is unattainable, but a demonstrably short time to remediate the CVEs that carry real risk.
The limits of the CVE system
A complete understanding includes what the CVE system does not cover. Not every vulnerability receives a CVE. Flaws in bespoke, in-house software, many issues found during a private penetration test, and undisclosed zero-days may have no CVE at all, because no one has requested or published one. The system also depends on timely enrichment, and periods of backlog can delay scoring. None of this diminishes the value of CVEs. It simply means that a CVE list is a map of publicly known vulnerabilities, not a complete inventory of your risk, and that testing your own systems remains essential.
Common misconceptions
“CVE and CVSS are the same thing.” They are not. A CVE is the identity of a vulnerability. CVSS is its severity score. One tells you which flaw, the other tells you how bad.
“If it has a low CVSS score, I can ignore it.” Not if it is in the CISA KEV catalog. Active exploitation outranks a modest severity score for prioritization.
“Every vulnerability has a CVE.” No. Custom software flaws, many pentest findings, and undisclosed zero-days often have no CVE. A CVE list is not a full picture of your risk.
See your network the way an attacker does — before one does!
Mercurius runs manual-led Red Team, penetration testing and cloud assessments that don’t just list vulnerabilities — they prove the exact path an adversary would take to your crown jewels, and how to close it.
Learn about the pentest and offensive security service from Mercurius
Frequently asked questions
What does CVE stand for? CVE stands for Common Vulnerabilities and Exposures. It is a public system of unique identifiers for known security vulnerabilities, maintained by MITRE and sponsored by the US agency CISA.
What is the difference between CVE and CVSS? A CVE is the unique identifier of a specific vulnerability, answering which flaw it is. CVSS is the scoring system that rates the severity of that vulnerability from 0.0 to 10.0, answering how bad it is. Each CVE typically has a CVSS score attached to it in the NVD.
Who assigns CVE numbers? CVE identifiers are assigned by CVE Numbering Authorities (CNAs), organizations authorized by the CVE Program. Many technology vendors act as CNAs for their own products, while MITRE operates and coordinates the overall system.
Does every vulnerability have a CVE? No. Only publicly known vulnerabilities that have been reported and accepted receive a CVE. Flaws in custom software, many issues found in a private penetration test, and undisclosed zero-days may have no CVE at all.
How should I prioritize CVEs? Start with the CISA Known Exploited Vulnerabilities catalog, which flags CVEs under active attack, then weigh the EPSS exploitation probability and the CVSS severity against the value of the affected asset. Prioritizing by active exploitation and business impact beats reacting to severity scores alone.
