CVE Vulnerabilities Explained: What They Are and Why They Matter

A CVE (Common Vulnerabilities and Exposures) is a standardized identifier assigned to a publicly known cybersecurity vulnerability. Each CVE entry provides a unique ID, a description, and references to related advisories, giving security teams a common language for tracking and discussing specific flaws. The CVE system is maintained by the MITRE Corporation and serves as the backbone of modern vulnerability management across the software industry.

What Is a CVE?

CVE stands for Common Vulnerabilities and Exposures. It is a dictionary of publicly disclosed security flaws, each assigned a unique identifier in the format CVE-YEAR-NUMBER (for example, CVE-2021-44228 for the Log4Shell vulnerability). The CVE system does not rate the severity of vulnerabilities — it simply catalogs them with a standardized reference that anyone in the cybersecurity community can use unambiguously.

The program was launched in 1999 by MITRE Corporation with funding from the U.S. Department of Homeland Security (DHS) and the Cybersecurity and Infrastructure Security Agency (CISA). Before CVE existed, different vendors and databases used their own naming schemes for the same vulnerability, leading to confusion and duplicated effort. CVE solved this by providing a single, authoritative numbering system.

As of early 2026, the CVE database contains over 330,000 entries and continues to grow rapidly — over 48,000 CVEs were published in 2025 alone. The MITRE CVE program relies on a network of CVE Numbering Authorities (CNAs) — organizations authorized to assign CVE IDs within their scope. Major CNAs include Microsoft, Google, Red Hat, Apache, and hundreds of other vendors and open source projects.

How the CVE Process Works

Discovery and Assignment

When a vulnerability is discovered — by a security researcher, vendor, or automated tool — it can be reported to the relevant CNA or directly to MITRE. The CNA evaluates the report and, if it meets the criteria (a security flaw in publicly available software that can be independently fixed), assigns a CVE ID.

Publication

Once assigned, the CVE entry is published to the CVE List with a description and references. The entry may initially be marked as “reserved” while the vendor works on a patch, then updated with full details upon coordinated public disclosure.

Enrichment

After publication, the National Vulnerability Database (NVD), maintained by NIST, enriches the CVE with additional data: severity scores (via CVSS), affected product configurations (CPE data), and references to patches and advisories. This enrichment makes CVE data actionable for vulnerability management tools.

CVE vs. CVSS vs. KEV: Understanding the Differences

These three acronyms are related but distinct. Confusing them is common, so here is a clear breakdown.

A CVE tells you what the vulnerability is. A CVSS score tells you how bad it is. A KEV listing tells you it is being actively exploited right now. Effective vulnerability management uses all three signals together.

The National Vulnerability Database (NVD)

The National Vulnerability Database is the U.S. government’s repository of standards-based vulnerability management data. NVD builds on the CVE list by adding:

• CVSS scores — severity ratings using the Common Vulnerability Scoring System
• CPE data — Common Platform Enumeration entries that map vulnerabilities to specific products and versions
• CWE classifications — Common Weakness Enumeration categories describing the type of flaw (e.g., buffer overflow, SQL injection)
• Fix references — links to vendor advisories and patches

NVD is freely accessible and is the primary data source for most vulnerability scanning tools. When a platform like sbomify, Grype, or OWASP Dependency-Track scans your software for known issues, it is typically checking component versions against NVD data.

CVE Funding and Governance

The CVE program has historically been funded through U.S. government contracts administered by CISA and DHS. In 2025, questions about the sustainability of MITRE’s CVE funding drew significant attention from the cybersecurity community. The concern was straightforward: the entire global vulnerability tracking ecosystem depends on a single program funded by a single government.

In response, the CVE Foundation was established to diversify funding and governance. The CVE Board, an international group of cybersecurity experts, provides strategic oversight. The expansion of the CNA network — now numbering over 400 organizations across 40+ countries — has also distributed the operational workload beyond MITRE alone.

Regardless of governance structure, the CVE system remains the de facto global standard for vulnerability identification.

Vulnerability Management with CVEs

Vulnerability management is the continuous process of identifying, evaluating, prioritizing, and remediating security flaws in software. CVEs are the fundamental building blocks of this process.

The Vulnerability Management Lifecycle

1. Discover — Inventory all software components in your environment (this is where SBOMs are critical)
2. Identify — Match your components against known CVEs using vulnerability scanners
3. Evaluate — Assess severity using CVSS scores, exploit availability (KEV status), and your own risk context
4. Prioritize — Not all CVEs require immediate action. Focus on high-severity vulnerabilities in internet-facing or critical systems, especially those listed in the CISA KEV catalog
5. Remediate — Apply patches, update dependencies, or implement mitigations
6. Verify — Confirm the fix was applied and re-scan to ensure the vulnerability is resolved

Vulnerability Scanners and Scanning Tools

Several categories of tools support CVE-based vulnerability management:

• Software Composition Analysis (SCA) tools scan open source dependencies for known CVEs. Examples include Grype, Snyk, and Trivy.
• Container scanners analyze Docker and OCI images for vulnerable packages. See our Docker SBOM guide for details.
• Network vulnerability scanners probe running systems for known flaws.
• SBOM-based analysis platforms like sbomify and OWASP Dependency-Track ingest SBOMs and continuously monitor components against new CVE disclosures.

See our resources page for a complete list of vulnerability scanning and SBOM analysis tools.

The key advantage of SBOM-based scanning is that it decouples vulnerability identification from the build process. Once you have an SBOM, you can re-scan it at any time as new CVEs are published — without needing access to the source code or build system.

How SBOMs Enable Rapid CVE Response

The value of a Software Bill of Materials becomes most obvious during a vulnerability incident. Consider the Log4Shell scenario (CVE-2021-44228, disclosed December 2021):

• Without SBOMs: Teams had to manually audit every application, check dependency files, search through build systems, and contact vendors to determine if they were using Apache Log4j. This took many organizations days or weeks.
• With SBOMs: A simple search across your SBOM repository for org.apache.logging.log4j:log4j-core returned a complete list of affected applications in minutes.

This is why compliance frameworks increasingly mandate SBOMs. The EU Cyber Resilience Act requires manufacturers to identify and document components in their products. Executive Order 14028 requires software vendors to the U.S. government to provide SBOMs. The CISA minimum elements specify that SBOMs should include unique identifiers (such as Package URL) that can be matched against CVE-affected component data.

To start generating SBOMs for your projects, see our language-specific SBOM guides covering Python, JavaScript, Java, Go, Rust, and more.

Notable CVEs That Changed the Industry

Several high-profile CVEs have shaped how the industry approaches vulnerability management:

• CVE-2014-0160 (Heartbleed) — A critical flaw in OpenSSL that exposed encrypted communications for millions of servers. Highlighted the risk of widely shared dependencies.
• CVE-2017-5638 (Apache Struts) — The vulnerability behind the Equifax breach, which exposed personal data of 147 million people. Demonstrated the consequences of slow patching.
• CVE-2021-44228 (Log4Shell) — A remote code execution flaw in Apache Log4j that affected millions of applications. Became the catalyst for widespread SBOM adoption as organizations struggled to identify affected systems.
• CVE-2024-3094 (XZ Utils) — A supply chain attack where a malicious contributor inserted a backdoor into the XZ compression library. Showed that vulnerabilities can be deliberately introduced, not just accidentally created.

Each of these incidents reinforced the same lesson: you cannot protect what you cannot see. SBOMs provide that visibility.

Best Practices for CVE Management

1. Maintain SBOMs for all your software. An accurate component inventory is the foundation of effective vulnerability management. Use automated tools to generate SBOMs as part of your CI/CD pipeline.

2. Automate vulnerability scanning. Integrate SBOM-based scanning tools into your build and deployment process. Continuous monitoring catches newly disclosed CVEs without manual effort.

3. Use multiple severity signals. Do not rely on CVSS scores alone. Factor in KEV status (is it being exploited?), your deployment context (is the component exposed?), and exploit maturity.

4. Establish a patching SLA. Define response timeframes based on severity. Critical CVEs in exposed systems should be addressed within days, not months.

5. Subscribe to advisories. Monitor the NVD data feeds, vendor security bulletins, and the CISA KEV catalog for timely notification of new CVEs affecting your stack.

6. Document your response process. When the next Log4Shell-scale event happens, you need a practiced runbook — not a scramble. SBOMs, pre-defined escalation paths, and automated alerting make the difference.

Frequently Asked Questions

What does CVE stand for?

CVE stands for Common Vulnerabilities and Exposures. It is a system for assigning unique identifiers to publicly known cybersecurity vulnerabilities. Each CVE ID (e.g., CVE-2021-44228) serves as a standard reference that security teams, vendors, and tools can use to unambiguously identify a specific flaw.

What is the difference between a CVE and a vulnerability?

A vulnerability is any security weakness in software that could be exploited. A CVE is the standardized identifier assigned to a publicly known vulnerability. Not all vulnerabilities have CVE IDs — only those that are publicly disclosed and meet the CVE program’s inclusion criteria receive a CVE number. Think of CVE as the naming system, and vulnerability as the broader concept.

Who assigns CVE numbers?

CVE IDs are assigned by CVE Numbering Authorities (CNAs). MITRE Corporation serves as the primary CNA and coordinates the overall program. Over 400 organizations, including major software vendors like Microsoft, Google, and Red Hat, are authorized to assign CVE IDs within their product scope. Researchers can also request CVE IDs through the CVE Request form.

How are CVEs used in vulnerability management?

CVEs are the foundation of vulnerability management. Organizations use vulnerability scanners and Software Composition Analysis tools to match their software components against known CVEs. When a match is found, the CVSS severity score and KEV status help prioritize remediation. SBOMs make this process more efficient by providing a complete component inventory that can be continuously rescanned.

What is the National Vulnerability Database (NVD)?

The NVD is the U.S. government’s repository of vulnerability data, maintained by NIST. It enriches CVE entries with severity scores (CVSS), affected product mappings (CPE), weakness classifications (CWE), and references to patches. Most vulnerability scanning tools use NVD as their primary data source.