The news that NIST has given up enriching most CVEs should not be surprising to anyone who has been watching the National Vulnerability Database slowly buckle under its own weight since early 2024. What should be surprising is how much of the security tooling world built itself on the assumption that a single government-funded agency would forever keep pace with an exponentially growing vulnerability disclosure ecosystem.
To understand why this matters, you need to understand what “enrichment” actually means in the CVE context.
What CVE Enrichment Is
A CVE identifier, like CVE-2024-3094 (the XZ backdoor), is just a label. MITRE’s CVE Program assigns these identifiers through a network of CVE Numbering Authorities (CNAs), which include major vendors like Microsoft, Google, and Red Hat, as well as research organizations. The CVE record itself contains a description and some basic metadata, but not much else.
Enrichment is what NIST’s National Vulnerability Database adds on top. For each CVE, NVD analysts compute or curate:
- CVSS scores: The Common Vulnerability Scoring System produces a numeric severity rating from 0.0 to 10.0, with subscores for attack vector, complexity, privileges required, user interaction, scope, confidentiality impact, integrity impact, and availability impact. NVD maintains both CVSS v3.1 and v4.0 scores.
- CPE data: Common Platform Enumeration entries describe exactly which software versions and hardware configurations are affected. This is the structured data that allows tools to say “your system has libssl 1.1.1q and CVE-X affects libssl 1.1.1 through 1.1.1r”.
- CWE classification: Common Weakness Enumeration categorizes the type of vulnerability, such as CWE-787 (out-of-bounds write) or CWE-89 (SQL injection). This feeds aggregate statistics and trend analysis.
- Reference links: Curated pointers to advisories, patches, PoC code, and writeups.
Without this enrichment, a CVE is roughly as useful as a bug report with no severity, no affected version range, and no patch link. Scanners like OWASP Dependency-Check, GitHub’s Dependabot, Snyk, Trivy, Grype, and hundreds of commercial products consume NVD data as their primary source of truth. They pull the CPE-to-package mappings and CVSS scores to tell you “upgrade this dependency, it’s a 9.8”.
How the Backlog Happened
In February 2024, NIST quietly stopped enriching the majority of new CVEs. Their public statement cited “a growing number of CVEs” and “program changes” without much specificity. Within weeks, security researchers started noticing that thousands of CVEs were sitting in an “Awaiting Analysis” state indefinitely.
By mid-2024, the backlog had grown past 10,000 unenriched CVEs. The number of CVEs published annually had been climbing for years: from around 6,000 in 2016 to over 28,000 in 2023, with no sign of slowing. NVD’s analyst team, working within government budget and staffing constraints, was never scaled to match that growth. The assumption was always that the volume would stabilize or that automation would compensate. Neither happened.
NIST did announce intentions to form a consortium of partners who could help with enrichment, but that effort moved slowly. In the meantime, the de facto situation was that most new CVEs were getting no NVD enrichment at all.
The latest news formalizes what had already become reality: NIST is acknowledging that enriching the bulk of CVEs is not something they can sustain.
A Fragility Years in the Making
The security tooling ecosystem made a bet. The bet was that a centralized, government-funded database would remain authoritative and timely indefinitely. That bet made sense in 2005, when CVE volumes were manageable and NVD was new. It looks much less sensible when you consider that the CVE ecosystem now spans tens of thousands of CNAs, open source projects, and security researchers publishing vulnerabilities at a pace no single organization can manually process.
The fragility showed up in another way in April 2025, when CISA’s funding for the CVE program itself briefly lapsed. MITRE’s contract to operate the CVE numbering infrastructure was within hours of expiring before CISA extended it at the last minute. The security community briefly panicked, a CVE Foundation was hastily formed to explore alternative governance, and the whole episode exposed that the identifier layer and the enrichment layer both had single-point-of-failure properties.
These are related but distinct systems. MITRE manages CVE IDs and the CNA network. NIST manages NVD enrichment. They depend on each other in that NVD enriches CVEs that exist, but a failure in either disrupts the pipeline that security tools depend on.
What Fills the Gap
Several alternatives have been gaining traction as NVD’s reliability has declined.
OSV (Open Source Vulnerabilities) is a Google-maintained database and schema focused on open source packages. It maps vulnerabilities to package ecosystems (PyPI, npm, Maven, Go modules, etc.) with precise version ranges rather than CPE strings. The OSV schema is more machine-readable than NVD’s CPE approach and is maintained by a broader set of contributors. Tools like OSV-Scanner, pip-audit, and govulncheck use it directly.
VulnCheck NVD++ is a commercial service that has been enriching CVEs independently and claims to process new CVEs significantly faster than NVD’s current pace. They offer an API compatible with NVD’s format, which makes it a drop-in replacement for tooling already consuming NVD.
Vendor-specific advisories have always existed, but tools are now giving them more weight. Red Hat, Debian, and Ubuntu maintain their own severity ratings that often differ from CVSS base scores, reflecting their assessment of exploitability in context. GitHub’s Advisory Database pulls from multiple sources and has its own review process.
EPSS (Exploit Prediction Scoring System) from FIRST.org complements CVSS by predicting the probability that a vulnerability will be exploited in the wild within the next 30 days. It does not depend on NVD enrichment in the same way and has become a useful triage signal independent of NVD.
For projects consuming vulnerability data programmatically, the OSV API is worth looking at:
curl -X POST https://api.osv.dev/v1/query \
-H 'Content-Type: application/json' \
-d '{"package": {"name": "requests", "ecosystem": "PyPI"}, "version": "2.25.0"}'That returns a list of vulnerabilities affecting that exact version, with affected ranges, severity info where available, and links to fixes. No NVD dependency in the critical path.
What This Means Practically
If you run a scanner that pulls from NVD directly or through a tool that relies on it, you are already getting incomplete data for anything published in the last year or more. The CVSS scores and CPE data that your risk dashboards display may simply be absent for a large fraction of recent CVEs.
The response from most mature security teams should be multi-source enrichment: pull from OSV for package ecosystems, fall back to vendor advisories for severity context, and use EPSS to prioritize what gets patched first. Treating any single database as authoritative has always been a category error; it just took NVD’s collapse to make that visible.
For tooling authors, the practical steps are:
- Add OSV as a data source alongside or instead of NVD for package ecosystem vulnerabilities.
- Do not fail closed on missing CVSS scores. A CVE without a score is not a zero-severity CVE.
- Consider pulling from multiple enrichment providers and merging the data, with recency and source priority rules.
- Track NVD enrichment lag as a metric and surface it to users when a vulnerability’s data may be stale or incomplete.
The Broader Lesson
Security infrastructure has a recurring problem with centralization. The CVE program, NVD enrichment, certificate transparency logs, OCSP responders, and threat intelligence feeds all tend to consolidate into single authoritative sources because that simplicity is valuable. Consumers want one place to query. Standards bodies want one canonical schema. The problem is that single sources have single budgets, single staffing levels, and single political dependencies.
NIST’s enrichment failure is not a story about government incompetence. It is a story about a system that was never designed to scale to 30,000 CVEs per year, operated by an agency whose funding and staffing are not elastic, providing a service that the private sector came to depend on as if it were guaranteed infrastructure.
The fix is not to find a better single source. It is to build tooling that federates across multiple sources, degrades gracefully when any one is incomplete, and treats enrichment as a commodity produced by many parties rather than a gift from one.