In December 2021, security teams around the world gave up a weekend to chase a flaw in Log4j, a Java logging library buried inside thousands of products. Vendors, scanners, news sites and government advisories all called it by the same name, CVE-2021-44228, and all gave it the same score, 10.0. That shared name and shared number let thousands of teams work on the same problem at once instead of arguing about which bug they meant and how bad it was.
On the CompTIA Security+ SY0-801 exam, CVE and CVSS sit under objective 2.1, which expects you to know how vulnerabilities are identified and how their severity is rated. This lesson covers CVE identifiers and who assigns them, how the NVD and CWE relate to CVE, and how to read CVSS scores and vector strings in versions 3.1 and 4.0. Using those scores to decide what to fix first is the next lesson.
A CVE ID gives one vulnerability one name everyone uses
Common Vulnerabilities and Exposures (CVE) is a public catalog of disclosed vulnerabilities, each with a unique identifier. It started in 1999 because every vendor and scanner named bugs differently, and nobody could tell whether two reports described the same flaw.
An ID looks like CVE-2021-44228. The middle part is a year, usually the year the ID was assigned or reserved, which is not necessarily when the flaw was found or disclosed. The last part is a sequence number of four or more digits with no upper limit, so CVE-2024-3094 and CVE-2023-34362 are both valid.
A CVE record holds the ID, a short description, the affected products and versions, and references to advisories and fixes. An ID can be reserved before details go public, so a vendor and a researcher can coordinate a fix under a known name. It is published when the advisory goes out, or rejected if it turns out to be a duplicate or not a vulnerability.
A CVE ID is not a patch, and on its own it tells you nothing about severity. Not every flaw gets one either; a bug in an application your company built for its own use never will. On the exam, when a scenario needs one consistent way to refer to the same vulnerability across a scanner report, a vendor bulletin and a ticket, the answer is the CVE ID.
CNAs assign the IDs and the NVD adds scores and product data
The CVE Program has been operated by MITRE with U.S. government sponsorship through CISA, under a board of industry, government and academic members. MITRE doesn't assign most IDs itself. CVE Numbering Authorities (CNAs) do: organizations authorized to assign IDs and publish records within an agreed scope. Most are vendors covering their own products, such as Microsoft, Cisco and Red Hat; others are open-source projects, national CERTs, bug bounty platforms and research firms. There are hundreds worldwide, and a CNA of last resort covers anything outside every other CNA's scope. In a typical case, a researcher reports a flaw to the vendor, the vendor reserves an ID as the CNA, and it publishes the record alongside its advisory on release day.
The National Vulnerability Database (NVD), run by NIST, is built on top of CVE. It ingests published records and enriches them with a CVSS score from NIST's own analysts (shown next to any score the CNA supplied, and the two can differ), one or more CWE entries classifying the weakness, and CPE (Common Platform Enumeration) names listing exactly which products and versions are affected so scanners can match findings to installed software.
Since early 2024 the NVD has gone through long stretches of enrichment backlog, during which many new CVEs carried only the CNA's data. CVE records can include CNA-supplied scores and weakness types directly, and many teams read vendor advisories rather than waiting for NVD analysis.
On the exam, keep the roles straight: CVE names the vulnerability, the NVD is the enriched database, CVSS is the scoring standard and CWE is the weakness category. SCAP, covered in the monitoring section, bundles several of these standards so tools can automate checks.