What is a CVE? Common Vulnerabilities and Exposures, explained
A CVE (Common Vulnerabilities and Exposures) is a unique identifier assigned to one publicly known vulnerability, in the form CVE-YYYY-NNNNN. It is a naming system, not a severity score: it lets everyone refer to the same flaw unambiguously. CVEs are what vulnerability matching maps your components to - the link between an SBOM entry and the specific known issues affecting it.
A CVE - Common Vulnerabilities and Exposures - is a unique, public identifier for a single known vulnerability. You have seen the format: an identifier of the shape CVE-YYYY-NNNNN, referring to one specific flaw that everyone in the industry can point to without ambiguity. That last part is the whole purpose. Before a shared naming system, the same vulnerability might be described five ways by five vendors; the CVE gives it one canonical name.
An identifier, not a judgment
The most common misunderstanding is treating a CVE as a measure of severity. It is not. A CVE is a name - it says which vulnerability, not how bad. Severity and urgency are separate layers attached to that name:
- The CVE identifies the flaw.
- CVSS scores how severe exploitation would be.
- EPSS predicts how likely exploitation is.
- The known-exploited catalog records whether it is already being exploited.
Keeping these distinct matters, because a queue sorted by “has a CVE” is meaningless - almost every dependency has CVEs somewhere in its history. The CVE is the join key that lets the severity and exploitation data find the right flaw; the prioritization happens in those other layers.
How the namespace stays clean
CVE identifiers are assigned by a distributed network of authorized organizations - vendors, coordination centers, and research bodies - each allocating IDs from blocks delegated to them under a coordinating program. The distribution is what lets the system scale to the volume of modern disclosure while keeping the guarantee that matters: one vulnerability, one identifier, referenced identically in advisories, scanners, and databases everywhere.
Where CVEs meet your software
CVEs are the currency of vulnerability matching. Your SBOM lists components and versions; vulnerability databases record which CVEs affect which versions; matching the two produces the list of CVEs affecting your software - a vulnerability disclosure report. Every step of the prioritization that follows hangs off the CVE identifier as the anchor.
This is also why CVEs have a temporal dimension that shapes bill-of-materials practice: new CVEs are assigned against old components constantly. A component clean today accumulates CVEs tomorrow without changing at all, which is the entire reason an SBOM is worth storing and monitoring rather than producing once.
The boundary worth knowing
A CVE exists when a vulnerability is publicly disclosed and assigned an identifier. Vulnerabilities found and fixed privately, or still under coordinated non-disclosure, may have no CVE. So “no CVEs” means “no known public vulnerabilities,” which is a real and useful statement, but not the same as “no vulnerabilities.” Honest security programs treat the CVE-matched view as the well-lit majority of the risk, not its entirety - which is why static analysis and other techniques that find undisclosed flaws complement CVE-based composition analysis rather than being replaced by it.
Frequently asked questions
Does a CVE tell me how severe a vulnerability is?
No. A CVE is only an identifier - a stable name for one vulnerability. Severity comes from separate scores attached to it, such as CVSS, and real urgency comes from exploitation signals like EPSS and known-exploited status. The CVE is the key that ties all that information to one specific flaw.
Who assigns CVE identifiers?
A distributed set of authorized organizations - vendors, coordination centers, and research bodies - assign CVE IDs from blocks delegated to them, under a program that keeps the namespace unique and non-overlapping. This is why a given vulnerability has exactly one CVE, referenced identically everywhere.
Are all vulnerabilities CVEs?
No. A vulnerability gets a CVE when it is publicly disclosed and assigned an ID; issues found and fixed privately, or not yet disclosed, may never receive one. So CVEs cover known, public vulnerabilities - which is most of what vulnerability management deals with, but not the entirety of software risk.