Common Vulnerabilities and Exposures (CVE) is a public catalog that assigns a unique identifier, such as CVE-2024-12345, to each publicly disclosed security vulnerability in software or hardware. The ID gives vendors, security tools, researchers and buyers one shared name for the same flaw. The program has long been operated by the nonprofit MITRE with US government funding, and IDs are issued through a network of authorized organizations, including many major software vendors.
At a glance
- A CVE ID names a specific, publicly disclosed vulnerability; it doesn’t rate it or fix it.
- Each entry includes a short description and references, such as the vendor’s advisory.
- Severity scores (usually CVSS) and exploit information are added by other sources.
- Scanners, patch tools and vendor advisories use CVE IDs so findings can be matched up.
- Not every flaw has a CVE, especially misconfigurations and issues in custom code.
What problem it solves
Before a shared naming system, the same vulnerability could be described differently by the vendor, each security tool and each researcher, making it hard to tell whether two reports were about the same thing or whether a patch covered a particular issue. CVE fixed that with one identifier per flaw.
For buyers, that common language makes several things practical: checking a vendor advisory against your scan results, asking a managed service provider whether a specific vulnerability is patched, answering a customer questionnaire about a widely reported flaw, and tracking remediation over time. Vulnerability management programs are largely organized around CVE IDs.
How it works
Discovery and request. A researcher, vendor or user finds a vulnerability and reports it. A CVE Numbering Authority (CNA), often the affected vendor itself, assigns an ID.
Publication. Once the vulnerability is disclosed, the CVE record is published with a description, affected products and references to advisories or fixes. Vendors often time disclosure with a patch, but not always.
Enrichment. Other databases, such as the US National Vulnerability Database, add severity scores, affected product versions and other details. Vendors may publish their own scores, which can differ.
Use in tools. Vulnerability scanners match software versions on your systems against known CVEs and report findings. Patch management tools map updates to the CVEs they fix. Threat intelligence and lists of known exploited vulnerabilities flag which CVEs attackers are actively using.
Remediation. Your team or provider patches, applies a workaround, or accepts and documents the risk, then rescans to confirm.
When it matters for buyers
- When a big vulnerability makes the news. The CVE ID is how you ask every vendor and provider “are we affected, and what are you doing?”
- When setting patch SLAs with an MSP. Agree timelines by severity and exploitation status, referenced to CVE IDs.
- When choosing a scanner or vulnerability management service. Compare how findings are prioritized, not just how many CVEs are found; our vulnerability management overview covers the options.
- When answering customer security questionnaires. Expect questions about how quickly critical CVEs are remediated.
Questions to ask vendors
- How do you prioritize CVEs: by score alone, or also by active exploitation, exposure and asset importance?
- What are your remediation timelines for critical and actively exploited CVEs, and how are they reported?
- How quickly do you publish advisories with CVE IDs for flaws in your own products?
- How do you cover vulnerabilities that have no CVE, such as misconfigurations?
- Can you show remediation status by CVE across our environment?
How it differs from CVSS
CVE answers “which vulnerability is this?” The Common Vulnerability Scoring System (CVSS) answers “how severe is it, in general?” with a score from 0 to 10 based on factors such as how it can be exploited and what an attacker gains. A CVE record often has a CVSS score attached, but the score describes the flaw in general, not your risk. A critical score on an isolated test server may matter less than a medium score on an internet-facing system that attackers are actively exploiting. A zero-day vulnerability is a different idea again: a flaw unknown to the vendor or without an available fix, which may or may not have a CVE ID yet. When attackers use one, that is a zero-day exploit or attack.