For the better part of two decades, the National Vulnerability Database was the unglamorous backbone of vulnerability management. Every time a CVE was published by MITRE, NIST would take that sparse identifier and turn it into something usable: a CVSS score to express severity, a CWE classification to identify the underlying weakness class, and CPE strings to map the vulnerability to specific affected products and versions. Scanners, SIEMs, dependency checkers, and patch management tools all consumed this enriched data downstream. The NVD was boring infrastructure, which is to say it was critical.
NIST has now effectively given up on that enrichment work for the bulk of incoming CVEs, according to reporting from Risky Business. This is not a surprise to anyone who has been watching the database closely. It is the formal acknowledgment of a failure that has been unfolding for over two years.
How Enrichment Works and Why It Matters
The CVE program, run by MITRE under contract with CISA, is responsible only for assigning identifiers and publishing minimal descriptions. A raw CVE record looks like this:
CVE-2024-XXXXX
Description: A heap buffer overflow in libfoo before 2.1.3 allows
remote attackers to execute arbitrary code.
References: [vendor advisory URL]That is enough for a human to understand roughly what happened, but it is not machine-consumable in any useful way. A vulnerability scanner cannot correlate that record against its asset inventory without knowing which CPE identifiers map to “libfoo before 2.1.3”. A risk prioritization tool cannot rank the issue without a CVSS base score. A compliance report cannot categorize the weakness without a CWE identifier.
NIST’s enrichment step at the NVD added all three. The CVSS scoring followed the published specification but still required human judgment to translate a prose description into the correct attack vector, complexity, privilege requirements, and impact ratings. CPE mapping required someone to match free-text product names to entries in the official CPE dictionary. CWE classification required understanding the root cause well enough to pick the right node in a taxonomy with hundreds of entries.
This was always labor-intensive work. NIST was doing it for every CVE published, and CVE volume has been rising steadily for years. In 2017, roughly 14,000 CVEs were published. By 2023, that number exceeded 28,000. The workload roughly doubled while NIST’s ability to staff the NVD program did not.
The Backlog That Revealed the Problem
In early 2024, security researchers and tooling vendors began noticing something odd: thousands of CVEs were sitting in the NVD for weeks or months without receiving enrichment. The CVSS fields were blank. The CPE configurations were missing. The CWE was unset. Tools that checked the NVD for this data came back empty.
NIST acknowledged the situation in February 2024, citing the end of an interagency support agreement and an increase in software and related services requiring analysis. The backlog was not a temporary blip caused by a staffing gap over a holiday. It was structural. The program had been operating beyond its sustainable throughput for long enough that a backlog of tens of thousands of records had accumulated.
The response from NIST was to establish a consortium model, inviting outside organizations to help contribute enrichment data. The NVD Consortium would theoretically distribute the work. Progress on standing up that consortium has been slow, and the backlog continued to grow throughout 2024 and into 2025.
The CVE Program Nearly Died Too
Separate from the NVD enrichment crisis, the CVE program itself had a near-death moment in April 2025. MITRE’s contract with CISA to operate the CVE program was set to lapse, and for a brief period it looked like there would be no renewal. The security community, justifiably alarmed, spent a week watching the situation closely before a short-term extension was announced. A non-profit called the CVE Foundation was spun up in response, with the goal of eventually moving the program to a governance structure independent of any single government contract.
That episode exposed something the security industry had been comfortable ignoring: a large portion of the vulnerability intelligence infrastructure that underpins commercial and open-source tooling runs on a relatively thin set of government-funded resources, with no real redundancy or fallback.
Who Has Been Filling the Gap
The practical response from the security tooling ecosystem has been to stop treating the NVD as the sole authoritative source and to build multi-source pipelines.
VulnCheck has been publishing enriched CVE data with lower latency than NIST, including CVSS scores and exploitation intelligence. Their NVD++ dataset covers a significant portion of the CVEs that NIST has left unenriched.
OSV.dev, Google’s open-source vulnerability database, focuses specifically on package-level vulnerabilities with precise version ranges. It does not try to replicate the NVD’s breadth, but for the dependency scanning use case it is often more accurate because its affected version data comes directly from package maintainers and security researchers rather than from CPE string matching.
The GitHub Advisory Database covers similar ground for software packages and integrates directly with Dependabot and the GitHub ecosystem. It has its own enrichment pipeline and does not depend on NVD data.
EPSS, the Exploit Prediction Scoring System maintained by FIRST, addresses a gap that NIST was never filling anyway: the probability that a vulnerability will be exploited in the wild within the next 30 days. A CVSS score tells you how bad exploitation would be; EPSS tells you how likely exploitation is. Both numbers are necessary for rational prioritization, and EPSS has no dependency on NVD enrichment.
For organizations running their own infrastructure, OpenVAS and Greenbone maintain their own vulnerability feeds, as does Tenable for its commercial customers. The practical reality is that any serious vulnerability management program was already pulling from multiple sources before NIST started falling behind.
What NIST’s Retreat Actually Breaks
The honest answer is that for well-resourced security teams, the impact is manageable. Commercial scanner vendors and major open-source tools have already adapted. If you are using Snyk, Dependabot, Trivy, or Grype for dependency scanning, those tools have their own data pipelines that supplement or replace NVD data.
The harder problem is for the long tail of integrations that assumed the NVD would always be there and always be current. Internal tooling built against the NVD API with no fallback. Compliance frameworks that cite NVD CVSS scores as the required severity basis. Government procurement processes that specify NVD data. Academic research papers that use NVD enrichment as ground truth for machine learning models. All of those assumptions are now broken.
There is also a subtler problem with CVSS score consistency. When NIST was scoring everything, there was at least a nominal single source of truth for base scores. Now, different data providers are producing different scores for the same CVE, not because any of them are wrong exactly, but because CVSS scoring involves judgment calls and different analysts make different calls. Downstream tools that aggregate vulnerability data across sources now have to decide which score to trust, or how to merge conflicting scores, which adds complexity and the possibility of systematic errors in either direction.
The Governance Question Nobody Has Answered
The NVD problem is ultimately a funding and governance problem, not a technical one. The data exists. The methodology is established. The tooling to automate parts of the enrichment process, particularly CVSS scoring and CPE mapping, has improved substantially. What is missing is a sustainable institutional home with reliable funding and a clear mandate.
The CVE Foundation is attempting to address the CVE assignment side of this. Nobody has yet stepped up with a credible plan for the enrichment side at NVD scale. NIST’s consortium model, if it ever fully materializes, is one path. A fully commercialized replacement, where vendors like VulnCheck absorb the function entirely, is another. Neither has the neutrality and universal trust that a well-funded government program would have, though a well-funded government program is precisely what NIST has been unable to sustain.
For now, the practical advice is straightforward: if your vulnerability management tooling has a hard dependency on NVD enrichment being current and complete, that dependency needs to be replaced or supplemented. The NVD as it existed from 2005 to roughly 2023 is not coming back.