Category: Vulnerability Management

Common Vulnerabilities and Exposures

Also known as: CVE, CVE List, CVE Program

Simply put

Common Vulnerabilities and Exposures (CVE) is a publicly available catalog that identifies and lists known computer security flaws in software and hardware. Each vulnerability in the list receives a unique identifier (such as CVE-2024-12345), which makes it easier for security teams, vendors, and tools to refer to the same issue consistently. The CVE system helps organizations coordinate their responses to security threats by providing a shared reference point.

Formal definition

The CVE Program maintains a standardized dictionary of publicly disclosed information security vulnerabilities, where each entry is assigned a unique CVE ID that maps to a specific vulnerability in a defined code base or product version. The program's primary purpose is to uniquely identify vulnerabilities and associate them with specific versions of code, enabling interoperability across vulnerability databases, scanning tools, and advisory feeds. CVE Records in the current JSON 5.0 schema may include metadata such as CVSS scores embedded by CVE Numbering Authorities (CNAs), though enrichment depth varies by CNA. The defined lifecycle states for CVE entries are Reserved, Published, and Rejected. CVE serves as a foundational enumeration layer; additional analysis, severity scoring, and remediation guidance are typically provided by downstream consumers such as the National Vulnerability Database (NVD), vendor advisories, and commercial threat intelligence platforms.

Why it matters

Without a shared naming convention for security vulnerabilities, organizations, vendors, and security tools would each describe the same flaw in different ways, leading to confusion, duplicated effort, and gaps in remediation. The CVE system solves this coordination problem by assigning a unique, permanent identifier to each publicly disclosed vulnerability. This common language allows a vulnerability scanner's output, a vendor's security advisory, and an organization's internal patch-tracking ticket to reference the exact same issue unambiguously, which is essential for efficient and accurate vulnerability management at scale.

CVE identifiers also serve as the foundational enumeration layer that downstream systems depend on. The National Vulnerability Database (NVD), vendor advisories, and commercial threat intelligence platforms all consume CVE data to add severity scoring, affected-product mappings, and remediation guidance. If a vulnerability lacks a CVE ID, it may be invisible to automated scanning pipelines and patch-management workflows, potentially leaving organizations exposed. For this reason, the assignment and timely publication of CVE IDs is a critical step in the broader vulnerability disclosure and response ecosystem.

The importance of CVE extends into regulatory and compliance contexts as well. Many security frameworks and contractual requirements reference CVE identifiers when defining expectations around vulnerability remediation timelines. Organizations that cannot map their asset inventories to known CVEs typically struggle to demonstrate due diligence during audits or incident investigations, making CVE literacy a practical necessity for security and engineering teams alike.

Who it's relevant to

Application Security Engineers

AppSec engineers encounter CVE identifiers daily in the output of static analysis tools, software composition analysis (SCA) scanners, and container image scanners. Understanding how CVE IDs map to specific code bases and product versions is essential for triaging findings, correlating scanner results across tools, and communicating risk to development teams in a consistent way.

Software Development Teams

Developers need to understand CVE identifiers to respond effectively when a dependency or component they use is flagged with a known vulnerability. Recognizing a CVE ID in a build pipeline alert and knowing how to look up its associated record helps developers assess impact and prioritize remediation within their release workflows.

Security Operations and Incident Response Teams

SOC analysts and incident responders use CVE identifiers to correlate threat intelligence feeds, vendor advisories, and exploit reports. A shared CVE ID enables rapid cross-referencing during an active incident, helping teams determine whether a particular vulnerability is being exploited in the wild and whether their environment is affected.

Vulnerability Management and Risk Teams

These teams rely on CVE as the foundational enumeration layer for tracking organizational exposure. CVE IDs are the common key that links asset inventories to vulnerability databases, severity scores from sources like NVD, and patch availability data, enabling prioritization and reporting against remediation SLAs.

Software Vendors and Open Source Maintainers

Vendors and maintainers who participate as CNAs are responsible for reserving and publishing CVE Records for vulnerabilities in their products or projects. Even those who are not CNAs must reference CVE IDs in their security advisories to ensure customers and the broader ecosystem can track and act on disclosed flaws.

Compliance and Governance Professionals

Many regulatory frameworks and contractual obligations reference CVE identifiers when defining expectations around vulnerability disclosure and remediation. Compliance teams use CVE-based reporting to demonstrate that known vulnerabilities are being tracked, prioritized, and addressed within required timelines.

Inside CVE

CVE Identifier

A unique alphanumeric string (formatted as CVE-YYYY-NNNNN+) assigned to a specific vulnerability, providing a stable, universal reference that enables unambiguous communication across vendors, tools, and databases.

CVE Record

The data object associated with a CVE ID, published in CVE JSON 5.0 format. A record typically includes a description of the vulnerability, affected products and versions, references to advisories or patches, and may include severity metrics such as CVSS vectors when provided by the assigning CNA.

CVE Numbering Authority (CNA)

An organization authorized by the CVE Program to assign CVE IDs and publish CVE Records within a defined scope. CNAs include major software vendors, open-source projects, coordination centers, and security research organizations.

CVE Record States

The official lifecycle states defined by the CVE Program for CVE Records: Reserved (ID assigned but details not yet published), Published (vulnerability details publicly available in the CVE Record), and Rejected (entry withdrawn or determined invalid, with the ID retained for historical tracking).

Affected Product and Version Data

Structured information within a CVE Record specifying which products, versions, and platforms are affected by the vulnerability, enabling automated tooling and vulnerability management workflows.

References

Links within a CVE Record pointing to external resources such as vendor advisories, patch information, technical write-ups, or coordination reports that provide additional context about the vulnerability.

Common questions

Answers to the questions practitioners most commonly ask about CVE.

Don't CVE entries include severity scores like CVSS ratings?

This is a common point of confusion. Historically, CVE entries did not contain severity scores, and CVSS ratings were associated with CVEs primarily through NVD enrichment. However, since the adoption of the CVE Record Format (JSON 5.0) in 2023 onward, CNAs may embed CVSS or other metric data directly within the CVE Record itself, and many now do. So while severity scoring originated as an NVD overlay, it is no longer accurate to say CVE entries never contain scores. In practice, consumers should check both the CVE Record and NVD for metrics, as coverage varies by CNA.

Does a CVE ID being assigned mean the vulnerability has been fully analyzed and confirmed exploitable?

No. A CVE ID in the Reserved state simply means the identifier has been set aside by a CNA for a potential vulnerability, and no details may yet be public. When the CNA publishes the record, it moves to Published state, but this reflects the CNA's assessment and description rather than a guarantee of independent exploitability confirmation. NVD may perform its own analysis workflow (sometimes labeled as 'Awaiting Analysis' or 'Undergoing Analysis' in NVD's system), but these are NVD workflow designations, not official CVE List states. The CVE List itself defines three states: Reserved, Published, and Rejected.

How should an organization integrate CVE monitoring into its vulnerability management program?

Organizations typically integrate CVE data by consuming feeds from both the CVE Program (via the CVE Services API or the cvelistV5 repository) and NVD (via its API or data feeds). These should be correlated with software inventory and software bill of materials (SBOM) data to identify which CVEs affect deployed assets. Automation through vulnerability scanners or SCA tools that map CVE IDs to software components is common practice. Organizations should note that there can be a lag between CVE publication by a CNA and NVD enrichment, so relying solely on NVD may delay awareness.

What should a development team do when a CVE is filed against their open-source dependency?

The team should first verify whether the specific version in use is affected by reviewing the CVE Record's affected version ranges. Next, they should assess whether the vulnerable code path is reachable in their application, since not all dependency vulnerabilities are exploitable in every usage context. If affected, the team should prioritize updating to a patched version, or if no patch is available, evaluate mitigating controls such as configuration changes or input validation. Tracking the CVE through both the CVE Record and NVD can provide additional context, including any CVSS metrics, references to advisories, and known exploit information.

How does the CNA structure work, and can my organization become a CNA?

The CVE Program operates through a federated model of CVE Numbering Authorities (CNAs). CNAs are organizations authorized to assign CVE IDs and publish CVE Records for vulnerabilities within their defined scope, which typically covers their own products or a specific domain. Major software vendors, open-source projects, and security research organizations commonly serve as CNAs. Organizations can apply to become a CNA through the CVE Program, which involves agreeing to CNA rules, defining a scope of coverage, and demonstrating the ability to follow CVE Record publishing processes. CNA-of-Last-Resort (CNA-LR) roles exist for gaps not covered by other CNAs.

What are the practical limitations of relying on CVE data for vulnerability prioritization?

CVE data alone is typically insufficient for prioritization. Not all CVE Records include severity metrics, and even when CVSS scores are present (whether embedded in the CVE Record by the CNA or added by NVD), they reflect general severity rather than organization-specific risk. CVE Records may lack exploit availability information, environmental context, or asset criticality data. Additionally, there can be delays between vulnerability discovery and CVE publication, and some vulnerabilities may never receive a CVE ID. Organizations generally supplement CVE data with exploit intelligence feeds, asset context, and frameworks like SSVC or EPSS to make risk-informed prioritization decisions.

Common misconceptions

CVE Records never contain severity scores; scoring is always added separately by NVD or other downstream databases.

Since the adoption of the CVE JSON 5.0 format (2023 onward), CNAs may embed severity metrics such as CVSS vectors directly in the CVE Record itself. Many CNAs now do so. However, not all CVE Records include scores, and NVD and other databases may independently add or supplement scoring. Practitioners should check both the CVE Record and downstream sources for the most complete severity information.

A CVE ID being assigned means the vulnerability has been fully analyzed, confirmed exploitable, and scored.

A CVE ID in the Reserved state indicates only that the identifier has been allocated. Publication of the CVE Record confirms public disclosure of details, but enrichment such as CVSS scoring, CWE classification, and CPE matching may be performed separately by NVD or other databases on their own timeline. The CVE Program itself defines the states Reserved, Published, and Rejected; analysis workflow stages like 'Awaiting Analysis' are NVD-specific designations, not CVE Program states.

Every genuine security vulnerability will have a CVE assigned to it.

CVE coverage, while extensive, is not exhaustive. A vulnerability typically receives a CVE ID only when it is reported to or discovered by a CNA, or when a researcher or vendor requests one. Vulnerabilities in less-visible software, internally discovered issues that are silently patched, or flaws in systems outside the scope of any active CNA may never receive a CVE ID.

Best practices

Integrate CVE monitoring into your vulnerability management pipeline by consuming the official CVE List (cvelistV5 repository or CVE Services API) and correlating with NVD or other enrichment sources for supplementary scoring and metadata.

Do not rely solely on CVE IDs for vulnerability coverage; supplement with vendor-specific advisories, GitHub Security Advisories, and language ecosystem databases (e.g., OSV, RustSec) to capture issues that may not yet have or may never receive a CVE.

When a CVE Record includes CNA-provided CVSS metrics, compare them with NVD-assigned scores where available, as scoring may differ due to differing assumptions about deployment context or scope.

Track CVE Record states and distinguish between CVE Program states (Reserved, Published, Rejected) and NVD analysis workflow stages to avoid misinterpreting a vulnerability's disclosure or analysis status.

For software supply chain security, map CVE IDs to components in your Software Bill of Materials (SBOM) to enable automated identification of affected dependencies and prioritize remediation based on exploitability and environmental context.

Establish a process for requesting CVE IDs for vulnerabilities you discover or disclose, either through the relevant CNA or via the CVE Program's web form, to ensure your findings are cataloged and broadly communicated.