A CVE (Common Vulnerabilities and Exposures) is a unique identifier assigned to a publicly known cybersecurity flaw — a standardized name like CVE-2021-44228 that lets vendors, researchers, and security tools all refer to the exact same bug without confusion. The CVE Program has been running since 1999, is sponsored by the U.S. Department of Homeland Security's CISA, and is operated by MITRE. Every CVE ID follows the format CVE-YYYY-NNNNN, where the year reflects either disclosure or reservation date, not necessarily when the bug was found. As of 2024, the program had grown to over 300 CVE Numbering Authorities (CNAs) — companies and organizations authorized to mint their own IDs — and the count of published CVEs crossed 40,000 in a single year for the first time. Understanding what a CVE is, and isn't, matters because most vulnerability scanners, SBOMs, and compliance frameworks are built entirely around this identifier system.
Who actually assigns a CVE ID?
A CVE ID is assigned by a CNA (CVE Numbering Authority), not by MITRE directly in most cases. MITRE runs the overall program and acts as the "CNA of last resort," but it delegates ID assignment to roughly 300+ authorized organizations, including major vendors like Microsoft, Google, Red Hat, and Apple, as well as bug bounty platforms like HackerOne and open source foundations like the OpenSSF. When a researcher finds a flaw in a Red Hat product, Red Hat's own CNA team typically assigns the CVE ID directly rather than routing it through MITRE. This distributed model is why a single company can have hundreds of CVEs assigned to its products in a year — each CNA manages its own block of ID ranges and publishes independently to the central CVE List, which then syncs to the National Vulnerability Database (NVD) for enrichment with CVSS scores and CPE data.
How does a bug become a CVE?
A bug becomes a CVE when it meets three specific criteria set by the CVE Program: it must be a security flaw, it must be independently fixable from other bugs, and it must have been acknowledged by the affected vendor or documented with supporting evidence. A researcher or vendor submits a request to a CNA, which reviews the report, checks for duplicates against the existing CVE List (which held roughly 240,000+ entries by the end of 2024), and assigns an ID — often reserved months before public disclosure. For example, CVE-2021-44228, the Log4Shell vulnerability in Apache Log4j, was reserved internally before Apache publicly disclosed it on December 9, 2021, with a CVSS score of 10.0. Not every reported issue qualifies: duplicate reports, issues without a clear security impact, or configuration weaknesses that aren't tied to a specific software defect are frequently rejected or marked as "disputed."
Is a CVE the same thing as a CVSS score?
No, a CVE and a CVSS score are two different things that get bundled together so often that people assume they're one system. The CVE is just the identifier — a name for the vulnerability. CVSS (Common Vulnerability Scoring System) is a separate severity-rating framework, currently on version 4.0 (released in late 2023, alongside CVSS 3.1 still in wide use), that scores a CVE from 0.0 to 10.0 based on exploitability and impact metrics. The NVD assigns most CVEs a CVSS score after the CNA publishes the base entry, which is why a fresh CVE ID can sit for hours or days with no severity rating at all — a gap that has caused real friction for security teams trying to triage on day one. A single CVE can also carry multiple CVSS scores from different sources: NVD's score, the vendor's own score, and sometimes a third-party score from a CNA, and they don't always agree.
Why do some CVE IDs stay stuck in "reserved" status for months or years?
A CVE stays in "reserved" status when the CNA has claimed the ID but hasn't yet published the technical details, which happens routinely during coordinated disclosure windows. Vendors commonly reserve an ID the moment a report comes in, then hold publication until a patch is ready — Google's Project Zero, for instance, enforces a standard 90-day disclosure deadline (shorter for actively exploited bugs). But the delay can stretch far longer: in 2024, security researchers publicly criticized MITRE and multiple CNAs for a backlog that left thousands of reserved CVE IDs unpublished for over a year, some referencing flaws that were already being exploited in the wild without a public advisory to warn defenders. This is one of the biggest practical gaps in relying on the CVE List alone — a vulnerability can be actively weaponized in a live campaign while its official CVE record still shows no description, no CVSS score, and no affected-version data.
What's the difference between a CVE and a security advisory like a GHSA or vendor bulletin?
A CVE is a bare identifier, while an advisory such as a GitHub Security Advisory (GHSA), a Red Hat Security Advisory (RHSA), or a vendor bulletin is the fuller writeup that explains affected versions, remediation steps, and often a proof of concept. Advisories frequently reference a CVE ID for cross-referencing, but they aren't required to have one — GitHub's advisory database contains thousands of GHSA entries for npm, PyPI, and RubyGems packages that never received a CVE at all because the maintainer never requested one through a CNA. This mismatch is a persistent headache in open source security: a package can carry a well-documented GHSA with a working exploit and still show up as "no known vulnerabilities" in a scanner that only checks against the CVE List, because the CVE side of the mapping was simply never filed.
How many CVEs get published each year, and is the volume actually manageable?
Roughly 40,000 Common Vulnerabilities and Exposures entries were published in 2024, up from about 29,000 in 2023 and roughly 25,000 in 2022 — a growth curve that has made manual CVE triage effectively impossible for any team without automated prioritization. At that volume, a security team reviewing even 50 CVEs a day would need over two years to work through a single year's output, and that's before accounting for the fact that most organizations run software affected by only a small fraction of any given year's total. The real operational question isn't "how many CVEs exist" but "how many of the CVEs in my environment are actually reachable and exploitable" — industry research has repeatedly found that fewer than 5% of CVEs flagged by a typical software composition analysis scan are in code paths that ever actually execute, which is why raw CVE counts are a poor proxy for real risk.
How Safeguard Helps
Safeguard cuts through CVE noise by running reachability analysis on top of every CVE match, determining whether the vulnerable function in a flagged package is actually called from your application's code paths before it ever reaches a human's queue. Griffin AI, Safeguard's security reasoning engine, correlates CVE data, CVSS and EPSS scores, and reserved-but-undisclosed advisory signals to explain in plain language why a given CVE matters (or doesn't) for your specific deployment. Safeguard generates and ingests SBOMs across your build pipeline so that every CVE published against a dependency — even ones covered by a GHSA but not yet a formal CVE — is mapped to the exact services and containers running it. When a fix is available, Safeguard opens an auto-fix pull request with the minimal version bump needed to resolve the CVE, so remediation doesn't require a security engineer to manually chase down every advisory.
