A CVE (Common Vulnerabilities and Exposures) is a unique identifier assigned to a publicly disclosed security vulnerability, following the format CVE-YEAR-NUMBER. The CVE Program, maintained by MITRE with funding from CISA and the U.S. Department of Homeland Security, provides a standardized naming system so that security teams, vendors, and tools can all refer to the same vulnerability unambiguously. Each CVE entry includes an ID, a description, and at least one public reference.
A CVE, or Common Vulnerability and Exposure, is a standardized identifier for a publicly known security flaw. NIST defines it as a list of entries, each containing a unique identification number, a description, and at least one public reference, for publicly known cybersecurity vulnerabilities. When your dependency scanner flags CVE-2024-3094 or your security questionnaire asks how you track known vulnerabilities, they're referencing this system.
The CVE Program is operated by MITRE and funded by CISA and the U.S. Department of Homeland Security. It doesn't score or rank vulnerabilities (that's CVSS) or predict exploitation likelihood (that's EPSS). It simply gives every publicly disclosed vulnerability a unique name so that scanners, advisory databases, and security teams are all talking about the same bug.
That naming function sounds mundane until you consider the alternative: every vendor inventing its own identifier, every scanner reporting the same flaw under a different name, and your team unable to deduplicate findings across tools. CVE is the connective tissue that makes vulnerability management work at scale.
The CVE system is more than a single database. It's a federated ecosystem with distinct roles.
CNAs are organizations authorized to assign CVE IDs within their own scope. Major software vendors like Google, Microsoft, and Red Hat are CNAs for their own products. Open-source projects, bug bounty platforms, and security research organizations can also serve as CNAs. As of 2025, there are over 400 CNAs worldwide, which is why CVE assignment can happen quickly for well-known software but lag for smaller projects without a dedicated CNA.
Once a CVE is assigned, it flows into NIST's National Vulnerability Database, which enriches the entry with a CVSS score, affected product configurations (CPE data), and references to patches or advisories. The NVD is what most scanners and compliance tools actually query. In 2024, the NVD faced a significant processing backlog, leaving thousands of CVEs without enrichment data for months, a reminder that the CVE and NVD are separate systems with separate resourcing.
The volume of CVEs published annually has grown dramatically. NIST registered roughly 28,000 CVEs in 2023 and over 40,000 in 2024. In 2025, 48,174 new CVEs were published, averaging 131 disclosures per day. That 2025 total alone accounts for roughly 15.8% of all CVEs ever recorded. For a startup security team of one or two people, that volume makes prioritization (using CVSS, EPSS, and KEV together) essential.
Understanding how a vulnerability moves through the CVE system helps you respond faster when one lands in your dependency tree.
A researcher, vendor, or automated tool discovers a vulnerability. They report it to the relevant CNA or directly to MITRE.
The CNA assigns a CVE ID once the vulnerability is confirmed. At this point, the CVE may be "reserved" with no public details while the vendor works on a patch.
When the advisory goes public, the CVE entry gets its description and references. This is when scanners start flagging it.
NIST's NVD adds the CVSS score, CPE entries, and links to patches. This enrichment can take days or weeks depending on NVD processing capacity.
Your team patches, upgrades, or mitigates. Compliance frameworks expect you to track this process and document your response timeline.
CVE doesn't work in isolation. It's the identifier layer in a prioritization stack that includes CVSS for severity scoring, EPSS for exploitation probability, and CISA's KEV catalog for confirmed active exploitation. A mature vulnerability management program uses CVE as the index key and these three systems to decide what gets patched this sprint versus what goes in the backlog.
This is also where the 2025 funding scare matters. In April 2025, MITRE's contract with the Department of Homeland Security to operate the CVE Program nearly lapsed, alarming the global cybersecurity community. CISA issued an emergency 11-month extension, and by January 2026, the program secured dedicated long-term funding. But the episode exposed how dependent the entire vulnerability management ecosystem is on a single program. The EU and other international coalitions have since launched backup CVE allocation systems as a hedge.
Fencer consolidates CVE findings from across your stack (code dependencies via SCA, container images, cloud infrastructure, and dynamic application scans) into a single prioritized view. Instead of checking multiple scanners with overlapping CVE results, Fencer deduplicates findings, layers in CVSS, EPSS, and KEV data for prioritization, and tracks remediation status through resolution. The compliance evidence your auditor needs (what was found, when, and how fast you fixed it) is generated automatically as a byproduct of the workflow.
No. CVEs are only assigned to publicly disclosed vulnerabilities in released software. Internal bugs you find and fix before release don't get CVEs. Neither do configuration errors specific to your environment, like an overly permissive S3 bucket policy. Vulnerabilities in proprietary, unreleased code or issues with no public advisory also fall outside the CVE system.
That said, the scope is broad: open-source libraries, commercial software, firmware, and operating systems are all covered. If your SCA scanner flags a dependency issue, it almost certainly has a CVE.
They're related but distinct. CVE (run by MITRE) assigns the identifier and provides a basic description. NVD (run by NIST) takes that CVE ID and enriches it with a CVSS severity score, affected product configurations, and links to patches. Most security scanners query the NVD, not the CVE list directly.
This distinction matters because they can fall out of sync: in 2024, the NVD had a months-long processing backlog where CVEs were assigned but not yet enriched, which meant scanners relying solely on NVD data were missing severity context.
You don't patch all of them. The whole point of a prioritization stack is to filter the noise. Start with what's actually in your environment: your SCA and container scans will surface the CVEs that affect your specific dependencies.
From there, layer in EPSS scores (which predict exploitation likelihood) and check CISA's KEV catalog (which lists CVEs under confirmed active exploitation). A two-person security team should focus on CVEs that are both in their stack and likely to be exploited, not the full firehose.
