What Is a CVE? The Naming System Behind Every Vulnerability You'll Ever Patch

CVE stands for Common Vulnerabilities and Exposures. It provides a widely used naming system for publicly disclosed cybersecurity vulnerabilities. Each vulnerability accepted into the CVE system receives a unique identifier, such as CVE-2021-44228, so security teams, software vendors, researchers, and security tools can refer to the same flaw consistently.

If you've ever looked at a vulnerability scanner, security advisory, or vendor patch note, you've seen CVE identifiers everywhere. They are the common language behind much of modern vulnerability management.

A CVE gives a vulnerability a common identity, but knowing its CVE is only the beginning.

This guide explains how the CVE system works, who assigns CVEs, how vulnerabilities are scored and prioritized, and why identifying a vulnerability is often much easier than actually fixing it. 

A CVE identifier follows a fixed format:

The prefix is always CVE. The year indicates when the CVE ID was assigned or reserved, which is not necessarily when the vulnerability was discovered or disclosed. The final segment is a unique sequence number consisting of four or more digits.

Without a common identifier, the same vulnerability could be described differently across a scanner, a vendor advisory, and a researcher's writeup, with no reliable way to tell they were referring to the same flaw. A shared identifier solves that problem: when everyone references CVE-2021-44228, they mean the same vulnerability.

But a CVE is essentially a name given to a known vulnerability, not a complete assessment of what that vulnerability means for you. It does not, by itself, tell you whether the vulnerability affects your specific environment, how likely it is to be exploited, how urgently you should prioritize it, or how quickly you can fix it. Other systems and security signals add that context, which we'll get to.

Vulnerabilities Versus Exposures

Traditionally, a vulnerability refers to a weakness that can be directly exploited to compromise a system. Think of a buffer overflow that enables code execution, an authentication flaw that allows someone to bypass access controls, or an injection vulnerability that lets an attacker execute unintended commands.

An exposure was originally used more broadly for security conditions that might not directly enable compromise but could make an attack easier. Examples include configurations or behaviors that reveal sensitive information or expose functionality that attackers can use as part of a larger attack.

In practice, however, modern CVE usage doesn't draw a sharp line between the two. The term “CVE” is commonly used to refer to a publicly disclosed vulnerability regardless of whether someone might historically have described it as a vulnerability or an exposure.

At the heart of vulnerability assessment is security impact. That impact is commonly considered in terms of confidentiality, integrity, and availability, the three principles often referred to as the CIA triad.

Who Runs the CVE Program?

The CVE Program dates back to 1999, when MITRE and members of the security community created a common way to identify software vulnerabilities. Today, the program operates as a global, federated effort involving hundreds of CVE Numbering Authorities (CNAs), with MITRE and the U.S. Cybersecurity and Infrastructure Security Agency (CISA) playing central roles in its operation and governance.

Over more than 25 years, CVE has become a foundational part of vulnerability management. Software vendors reference CVE IDs in security advisories, scanners use them to report findings, and security teams use them to correlate vulnerability information across different tools and sources.

That dependence became especially visible in April 2025.

On April 15, MITRE informed the CVE Board that its U.S. government contract supporting the program was set to expire the following day. The announcement raised concerns across the cybersecurity community about potential disruption to a system that security tools and organizations around the world rely on. Government support was subsequently continued, preventing an interruption in CVE services. 

At the same time, a group of longtime CVE Board members formally launched the CVE Foundation, an independent nonprofit intended to help build a more sustainable and globally diversified funding and governance model for CVE.

The episode highlighted something easy to overlook: CVE may look like a simple naming convention, but maintaining that common language requires a substantial global coordination effort.

How a Flaw Becomes a CVE

A vulnerability typically goes through several stages before you see it published as a CVE.

1. Discovery

A vulnerability can be discovered by anyone: a software vendor's security team, an independent researcher, an academic, a bug bounty participant, or another security organization.

The finder will often report the vulnerability privately to the affected vendor or project, giving maintainers time to investigate and develop a fix before technical details become public.

2. CVE Assignment

If the vulnerability meets the CVE Program's requirements, a CVE Numbering Authority (CNA) can assign it a CVE ID. CNAs are organizations authorized by the CVE Program to assign CVE IDs within a defined scope. They include major software vendors, open-source organizations, national and industry CERTs, security companies, and other organizations.

For example, Microsoft and Google are CNAs for vulnerabilities within their respective scopes.

A CVE ID can also be reserved before the vulnerability is publicly disclosed. This is why you may sometimes encounter a CVE marked “RESERVED”: an identifier has been assigned, but the details are not yet public.

3. Publication

Once the vulnerability is publicly disclosed, its CVE record can be published. The record provides the CVE ID along with information such as a description, affected products or versions, and references to advisories or other relevant sources.

At this point, vendors, researchers, security tools, and defenders have a common identifier for talking about the same vulnerability.

4. Enrichment

A published CVE can then be supplemented by other vulnerability databases and security sources.

One of the best known is the National Vulnerability Database (NVD), maintained by the National Institute of Standards and Technology (NIST). NVD uses CVE records as a foundation and adds structured information that can include severity scoring, weakness classifications, affected-product information, and additional references.

The distinction is useful:

What about responsible disclosure?

CVE assignment and public disclosure are related, but they are not the same thing. Security researchers often give vendors time to investigate and patch a vulnerability before releasing technical details publicly.

Google Project Zero, for example, uses a defined disclosure policy that generally gives vendors 90 days to address reported vulnerabilities. Other researchers and organizations follow different timelines.

The important point is that these are disclosure policies, not rules of the CVE Program. A vulnerability can receive or reserve a CVE ID independently of the timeline used to disclose its technical details.

Scoring Severity: CVSS and Its Limits

To turn "there's a flaw" into "how severe could it be," the industry uses the Common Vulnerability Scoring System (CVSS), an open framework maintained by FIRST (the Forum of Incident Response and Security Teams). CVSS produces a numerical score from 0.0 to 10.0 that reflects the technical severity of a vulnerability.

The current version is CVSS v4.0, released in November 2023. It organizes vulnerability characteristics into four metric groups: Base, Threat, Environmental, and Supplemental. CVSS scores can then be mapped to severity ratings:

Here's the catch that every security team eventually encounters: CVSS measures severity, not your organization's risk. A vulnerability rated 9.8 may be extremely severe, but its actual risk to you depends on factors CVSS alone cannot determine, such as whether the affected component is present, reachable, exposed, or important to your environment.

That gap is why security teams increasingly supplement CVSS with additional signals. EPSS (Exploit Prediction Scoring System) estimates the probability that a published CVE will be exploited in the wild in the next 30 days. CISA's Known Exploited Vulnerabilities (KEV) Catalog identifies vulnerabilities for which there is evidence of exploitation in the wild.

Put simply: CVSS helps describe severity, EPSS estimates exploitation likelihood, and KEV tells you where exploitation is already known to have occurred. None of them alone represents your organization's risk.

This is the logic behind CleanSight: rather than presenting a raw CVE list in isolation, it maps vulnerabilities to the containers in your environment and brings signals such as CVSS, EPSS, and KEV together to help teams understand which findings deserve attention. 

CVE Versus CWE: Instance Versus Category

One more distinction worth locking down, because these two acronyms get mixed up constantly.

A CVE identifies a specific publicly disclosed vulnerability in a particular product or component.

A CWE (Common Weakness Enumeration) describes a category of weakness that can lead to vulnerabilities. CWE-79, for example, covers cross-site scripting; CWE-89 covers SQL injection; and CWE-416 covers use-after-free.

Think of it this way: CWE describes the pattern; CVE identifies a specific instance. Many different CVEs can result from the same underlying CWE.

Putting It All together

By now, we've covered several acronyms: CVE, CNA, NVD, CVSS, EPSS, KEV, and CWE. Each answers a different question about a vulnerability.

An easy way to think about the vulnerability management stack is:

CVE = What vulnerability are we talking about? 

CVSS = How severe could it be? 

EPSS = How likely is it to be exploited? 

KEV = Is it known to be exploited? 

Environment & context = Does it actually matter to me? 

Remediation = What do I do about it?

Can Attackers Exploit Vulnerabilities Once They’re Public?

Yes, and this is the uncomfortable double edge of public disclosure. Disclosure helps defenders understand and fix vulnerabilities. But once enough technical detail becomes public, attackers can study the same information.

For widely deployed software, the race can move quickly. Log4Shell (CVE-2021-44228) is a textbook example: exploitation attempts were observed very quickly after public disclosure, leaving defenders with little time between learning about the vulnerability and responding to active attacks.

There's another complication: the danger can exist before a CVE does. The xz/liblzma backdoor (CVE-2024-3094), for example, involved malicious code deliberately introduced into a widely used open-source project. The threat existed before defenders had a CVE identifier to track it.

The point is this: public disclosure can become a starting gun that both sides can hear. It gives defenders the information they need to respond, but it can also accelerate the race to exploit vulnerable systems.

The Catch: Knowing the CVE Isn't Fixing It

Now we arrive at the question this whole post has been building toward. If CVEs are so useful, why doesn't a fully cataloged, well-scored vulnerability make you safe?

Because identifying and prioritizing a vulnerability is not the same as remediating it. The CVE system gives you a common identifier. CVSS, EPSS, KEV, and environmental context can help you understand its significance. None of them delivers the fix.

And for software built on layers of upstream components, remediation can be complicated for two structural reasons.

First, the fix may not be yours to make. When a vulnerability exists in an upstream library or package inside your container, such as OpenSSL, glibc, or zlib, remediation can depend on a chain of upstream actions. A maintainer releases a fix, a distribution or base-image provider incorporates it, your image is rebuilt, your application is tested, and finally the updated image reaches production.

This is closely related to what Google's Project Zero calls the “upstream patch gap”: a vulnerability may be fixed upstream while downstream users remain exposed because that fix has not yet propagated into the software they actually run.

Second, vulnerability findings can be noisy. Different scanners may report different results for the same image because they use different vulnerability databases, package-detection methods, version-matching logic, and update cycles.

And presence does not always equal meaningful exposure. A vulnerable component may exist inside an image even when the affected functionality is not used or reachable in the application's context. Security teams still have to determine which findings represent meaningful exposure and which do not.

So you're left with the fundamental gap: the ecosystem has become very good at naming, scoring, and detecting vulnerabilities. But detection is not remediation. If the vulnerable component comes from upstream, you may still depend on someone else to produce the fix you need.

How CleanStart Changes the Equation

Closing that gap requires changing where remediation begins. Traditional container images are often built on pre-built base images, inheriting their packages, dependencies, and vulnerabilities. CleanStart takes a different approach.

Build from source, reduce inherited risk. CleanStart builds container images from verified sources rather than relying on pre-built upstream binaries. Combined with minimal image composition, this reduces unnecessary packages and helps eliminate many of the inherited vulnerabilities commonly carried forward from traditional base images.

Cut vulnerability noise. CleanStart combines vulnerability analysis with deeper context to distinguish vulnerabilities that require action from findings that do not affect the delivered artifact. Where appropriate, VEX attestations provide machine-readable evidence about a vulnerability's applicability rather than simply suppressing the finding.

Shorten the remediation cycle. Because CleanStart controls the build pipeline for its artifacts, affected images can be rebuilt and reissued when upstream fixes become available, reducing dependence on traditional downstream packaging cycles.

Proof travels with the artifact. CleanStart images include provenance and supporting software supply chain metadata, giving security teams evidence about what is inside an artifact and how it was built.

None of this makes CVEs less important. Organizations still need the shared vocabulary, severity information, exploit intelligence, and disclosure ecosystem around them. What changes is their position in the remediation chain. Instead of accepting vulnerability inheritance as the starting point, CleanStart delivers verified software artifacts designed to reduce inherited risk and give organizations greater control over remediation.

The Takeaway

The CVE system gives the security industry a common way to name and track known vulnerabilities. Combined with systems such as CVSS, EPSS, KEV, and vulnerability databases, it gives defenders a powerful foundation for understanding what vulnerabilities exist and which ones deserve attention.

But knowing about a vulnerability is not the same as fixing it.

For software built on layers of upstream components, remediation may depend on maintainers, distributions, base-image providers, and internal rebuild cycles before a fix finally reaches production.

The better question, then, isn't only “How quickly can we find CVEs?” It is also “How do we reduce the number of vulnerabilities we inherit in the first place, and how quickly can we remediate the ones that remain?”

Want to see the difference on your own workloads? We'll compare one of your production images against its CleanStart equivalent and show you the difference in inherited vulnerability exposure. Book a Demo