Meta Description: NIST is no longer enriching most CVEs. Here's why the NVD backlog forced this change and what your dev team needs to do about it now.
The Single Source of Truth Just Stopped Being One
On April 15, 2026, the US National Institute of Standards and Technology (NIST) made a quiet but seismic announcement: it will no longer enrich most CVE entries in the National Vulnerability Database (NVD).
This isn't a temporary measure or a funding delay. It's a structural capitulation. The agency admitted it cannot keep up with the volume of vulnerabilities being reported, and under current budgetary constraints, it never will.
If your team's security tooling, vulnerability scanning, or patch prioritization relies on NVD data — and most do — this affects you directly.
How We Got Here
The NVD backlog started in early 2024. A handful of unprocessed CVE entries — around 2,100 — ballooned into nearly 30,000 by year-end. Despite efforts to catch up, the gap kept growing.
The numbers tell the story:
- 2025: CVE submissions increased by 263%
- 2025: NIST enriched 45% more CVEs than the previous year
- Result: They still fell further behind
Two structural forces made this inevitable. First, the sheer explosion of vulnerability disclosures — over 48,000 CVEs were assigned in 2025 alone. Second, budget cuts to DHS and CISA under the current administration reduced NIST's capacity to process them.
Then there's the incoming wave: AI-powered vulnerability scanners are expected to flood the system with even more disclosures, many of which will be low-quality "CVE chaff" — real but trivial bugs in obscure libraries with 100 GitHub stars.
NIST's solution is a triage approach. Going forward, they'll only enrich three categories of CVEs:
- CVEs listed in CISA KEV — vulnerabilities known to be actively exploited
- CVEs in software used by US federal agencies
- CVEs in "critical software" — OS, browsers, security tools, firewalls, VPNs, backup software
Everything else gets added to NVD as a bare entry — no independent analysis, no enriched metadata, no verified severity scoring.
What Breaks When NVD Stops Being Complete
The immediate impact falls on the vulnerability management industry. Companies that built scanners, dashboards, and reporting tools on top of NVD data are now working with an incomplete dataset.
False negatives in your tools. If a CVE isn't enriched by NIST, most tools won't surface it. Your team won't be alerted. The scanner says "all clear" — but it's only checking a shrinking pool of analyzed vulnerabilities.
Self-reported severity scores. NIST will stop providing independent CVSS scores and instead display whatever the CVE submitter assigned. Here's the problem: many CVE submitters are the vendors whose software has the vulnerability. There's a long history of vendors downgrading their own severity scores to minimize impact. Without NIST's independent assessment, this becomes the default.
The "not scheduled" black hole. The existing backlog is being moved to a status that essentially means "we might get to it someday." For security teams tracking specific CVEs in that backlog, this is a dead end.
As Sooraj Shah from Aikido Security put it: "The era of relying on one database as a source of truth is officially over."
The Deeper Problem: CVEs Were Never Enough
The NVD change is significant, but it exposes a vulnerability management problem that existed long before this announcement.
CVEs only cover what gets formally disclosed. Maintainers — even at major vendors — regularly fix security issues without reporting them. Silent patches, vague changelog entries, and "miscellaneous bug fixes" that are actually security vulnerabilities are common.
Aikido Security's data backs this up: in 2024, 67% of packages where they found vulnerabilities through changelog and commit analysis were never publicly disclosed to any database — not NVD, not GitHub Advisory, not MITRE, nowhere.
The Axios prototype pollution vulnerability (affecting a library with 56 million weekly npm downloads) was silently patched without disclosure. This is not an edge case.
The NVD shrinking its coverage just makes an existing gap more visible.
What Your Team Should Do Now
If you've been treating NVD as your primary vulnerability intelligence source, you need to diversify. Here's a practical approach:
1. Multi-Source Your Vulnerability Intelligence
Stop relying on a single database. Layer multiple sources:
- CISA KEV — actively exploited vulnerabilities (high signal)
- GitHub Advisory Database — open-source specific, often faster than NVD
- EUVD — the EU's emerging vulnerability database (nascent but growing)
- Vendor security advisories — direct from the source
- Package manager alerts — npm audit, pip audit, Snyk, Dependabot
2. Invest in Changelog and Commit Monitoring
Tools that analyze changelogs, release notes, and commit messages can catch silent patches before they're formally disclosed. If your dependency management doesn't include this layer, you're flying blind on the majority of real vulnerabilities.
3. Contextualize, Don't Just Count
The NVD change actually reinforces a best practice: stop treating all CVEs equally. Focus on:
- Exploitability: Is there a known exploit in the wild? (KEV-listed)
- Reachability: Is the vulnerable code path actually reachable in your application?
- Business impact: What's the blast radius if this vulnerability is exploited?
A thousand low-severity CVEs in dependencies you barely use matter less than one actively exploited vulnerability in your authentication library.
4. If You Build Security Tooling
If your product ingests NVD data, you need to:
- Accept that NVD coverage will shrink over time
- Build enrichment pipelines that combine NVD with other sources
- Consider using LLMs to analyze changelogs and patches directly (this is what the next generation of vulnerability intelligence tools are doing)
- Surface confidence levels — be honest with users about what's verified vs. unverified
The Startup Opportunity
This is a rare moment where a government infrastructure gap creates a real market opportunity. The vulnerability intelligence space is about to get competitive:
- Multi-source aggregation — tools that unify CVE, advisory, changelog, and dark web intelligence
- AI-powered enrichment — using LLMs to independently assess vulnerability severity and impact when NIST won't
- Developer-first security — shifting from "here's a list of 500 CVEs" to "here are the 3 that actually matter in your codebase"
The companies that solve for NVD's gap won't just replace it — they'll build something better.
FAQ
Q: Will NIST stop publishing CVEs entirely? A: No. All CVEs will still be added to the NVD. The change is about enrichment — the detailed metadata, independent severity scoring, and cross-referencing that makes the data useful. Most new CVEs will exist as bare entries without analysis.
Q: Which CVEs will NIST still enrich? A: Three categories: CVEs in CISA's Known Exploited Vulnerabilities catalog, CVEs in software used by US federal agencies, and CVEs in "critical software" including operating systems, browsers, security tools, firewalls, VPNs, and backup software.
Q: Why can't NIST just get more funding? A: The Trump administration's cuts to DHS and CISA budgets have constrained NIST's capacity. Combined with a 263% increase in CVE submissions, the gap between resources and demand became unbridgeable without a structural change in approach.
Q: What's the risk of self-reported CVSS scores? A: Vendors who issue CVEs for their own software often assign lower severity scores than independent analysts would. Without NIST's independent scoring, the default becomes whatever the vendor says — creating an incentive to downplay vulnerabilities.
Q: How should small dev teams adapt? A: Enable automated dependency scanning (Dependabot, Snyk, or npm audit), monitor CISA KEV for critical vulnerabilities, and subscribe to security advisories for your core dependencies. You don't need enterprise tooling — just multiple sources instead of one.