In depth
CVE IDs are issued by CVE Numbering Authorities (CNAs) — vendors (Microsoft, Red Hat, Cisco, Apple, Google), CERT teams, bug-bounty platforms (HackerOne, Bugcrowd) and the MITRE root CNA for vulnerabilities outside any other CNA's scope. Each CNA has a specified scope and an assigned block of IDs they can issue. Modern CVE issuance is decentralised and largely self-service for in-scope vulnerabilities; the days when a researcher had to email MITRE and wait three weeks for an ID are long gone.
Once a CVE is published, it flows downstream into the NVD (where NIST adds CVSS analysis and CPE matching), into vulnerability-management platforms, into SBOM-cross-referencing pipelines, and into the CISA Known Exploited Vulnerabilities catalog if the vulnerability is confirmed exploited in the wild. The natural enrichment companions are CWE for taxonomy, EPSS for exploit-likelihood, and CVSS for severity.
A common misconception is that "a CVE" means "a vulnerability." A CVE is the identifier; the vulnerability is what it identifies. Some vulnerabilities have multiple CVEs (one per affected product version chain), and some software defects that look like vulnerabilities are explicitly excluded from CVE scope (intended functionality, configuration errors not exposed by default). For procurement and compliance reporting, a CVE ID is the lingua franca for talking about a specific vulnerability across organisational boundaries. See VAPT services for context where CVE matching feeds into engagement scope.