In February 2024, the National Vulnerability Database quietly stopped keeping up with its own workload. NIST announced it was slowing enrichment — the CPE, CVSS, and CWE tagging that turns a raw CVE ID into something a scanner can actually act on — citing "an increase in software and hardware and a corresponding increase in vulnerabilities." By mid-2024, tens of thousands of published CVEs sat in "Awaiting Analysis" status with no severity score and no affected-product mapping. Two years later, the backlog has shrunk but never fully cleared, CVE volume keeps climbing past 40,000 disclosures a year, and the number of CVE Numbering Authorities publishing directly has tripled. Security teams that built their vulnerability programs around NVD as the single source of truth are now finding gaps, delays, and conflicting severity scores. This piece covers what actually changed, where the data gaps are, and how AI and multi-source pipelines are being used to close them — and where they still fall short.
What actually happened to the NVD, and is it fixed?
No — the NVD enrichment backlog was reduced, not eliminated. After the February 2024 slowdown announcement, NIST brought on contractor support (including Analygence) and CISA launched its own parallel "Vulnrichment" effort in May 2024 to add CVSS, CWE, and CPE data to CVEs that NVD hadn't touched. By late 2024, NVD was clearing new CVEs faster, but a large stock of older, un-enriched records remained, and CISA's own effort covers only a subset of high-priority CVEs rather than the full catalog. The practical effect: a CVE ID published today may show up in your scanner with no CVSS score for days or weeks, or with a score sourced from CISA's enrichment rather than NVD's — two pipelines now doing the job one used to do.
How many CVEs are missing critical data right now?
Thousands, and the exact number moves week to week because "Awaiting Analysis" is a live queue, not a fixed backlog. At the peak of the 2024 slowdown, independent trackers and researchers cited figures north of 20,000–30,000 CVEs sitting without CVSS/CPE data at NVD, out of roughly 240,000+ CVEs in the CVE.org catalog at the time. The CVE program itself crossed the 240,000-ID mark in 2024 and is adding more than 40,000 new identifiers a year — a volume increase driven partly by the growth in CNAs (CVE Numbering Authorities), which passed 300 organizations in 2024, up from roughly 100 a few years earlier. More CNAs means more CVEs get filed directly by vendors and open-source maintainers, bypassing NVD's central enrichment queue entirely — which is good for speed but bad for consistency, since not every CNA scores severity the same way NVD did.
Where else can teams get vulnerability data besides NVD?
Several parallel sources now carry real signal that NVD either doesn't have or publishes late. CISA's Known Exploited Vulnerabilities (KEV) catalog — which only lists CVEs with confirmed in-the-wild exploitation — has grown past 1,300 entries since its November 2021 launch and is the closest thing to a "drop everything and patch this" list. FIRST's Exploit Prediction Scoring System (EPSS) gives a probability of exploitation in the next 30 days, updated daily, which is a very different signal than a static CVSS base score. OSV.dev (Google-backed) and GitHub Security Advisories track ecosystem-specific vulnerabilities — npm, PyPI, Go modules, RubyGems — often faster than NVD because maintainers file directly. Individual vendor PSIRTs (Red Hat, Microsoft, Cisco) frequently publish their own severity assessments that diverge from NVD's, because they know their actual deployment context and NVD doesn't. A team relying on one feed is, by definition, missing at least one of these.
Can AI actually close the NVD enrichment gap?
Partially — AI is being used on both sides of this problem, as a fix and as a source of new noise. On the fix side, NIST and CISA have both explored machine-learning-assisted triage to speed up CPE matching and CVSS scoring, and several commercial vulnerability intelligence vendors now use LLMs to parse advisory text, vendor changelogs, and commit diffs into structured severity and affected-version data faster than manual analysts can. On the noise side, 2024–2025 saw a documented rise in AI-generated vulnerability reports and low-quality CVE submissions — automated scanners and LLM-assisted "researchers" filing CVEs for issues that aren't exploitable or don't meet CNA quality bars, which several CNAs have publicly pushed back on. The net effect is that AI can meaningfully speed up enrichment of legitimate CVEs, but it also increases the volume of low-signal entries that a human or automated triage layer still has to filter out — so AI alone doesn't remove the need for cross-referencing multiple sources.
What's the actual risk of relying on a single vulnerability feed?
The risk is acting on a severity score that doesn't reflect real exploitability or missing an actively-exploited flaw entirely. A CVE can carry a CVSS base score of 9.8 from NVD while sitting outside your actual attack surface — unreachable code, a disabled feature flag, a dependency that's present but never invoked — and a team that patches by CVSS alone burns engineering time on that fix while a lower-scored but actively-exploited CVE from the KEV catalog goes unpatched. Conversely, a CVE stuck in NVD's "Awaiting Analysis" queue with no CVSS score at all can get deprioritized by scanners that filter on score thresholds, even if it's already in CISA KEV or actively discussed in the wild. Both failure modes trace back to the same root cause: treating one vulnerability database as complete when none of them, individually, currently is.
How Safeguard Helps
Safeguard treats NVD, CISA KEV, EPSS, OSV, GitHub Security Advisories, and vendor PSIRTs as inputs to correlate rather than a single feed to trust, so a gap or delay in any one source doesn't stall triage. Griffin, Safeguard's AI analysis engine, cross-references these feeds against your actual SBOMs — generated automatically from your build artifacts or ingested from existing sources — and runs reachability analysis to determine whether a vulnerable function is actually called in your codebase before it gets escalated. That collapses the CVSS-only false-priority problem: a critical-scored CVE in unreachable code gets deprioritized, while a KEV-listed or high-EPSS vulnerability in a reachable path gets surfaced even if NVD hasn't scored it yet. Where a fix exists, Safeguard opens an auto-fix pull request with the corrected dependency version pinned, so remediation doesn't wait on a human to reconcile five different data sources first.