The NVD Just Admitted Defeat — And Your Vulnerability Scanner Is About to Feel It

For twenty years, security teams treated the National Vulnerability Database like the sun: a steady, centralized source that everything else orbited around. On April 15, 2026, NIST quietly turned off the lights on that model. Full enrichment of every CVE is officially no longer the goal, and any scanner still built on the assumption that NVD will do the heavy lifting is now flying blind on the majority of new vulnerabilities.

That’s not hyperbole — it’s math. According to NIST, annual CVE submissions grew 263% from roughly 18,000 in 2020 to more than 48,000 in 2025. Even after enriching nearly 42,000 CVEs in 2025 (45% more than any prior year), NIST said productivity gains weren’t enough. So the agency did the only rational thing: it triaged. And the fallout is going to reshape how every AppSec team, every SBOM tool, and every AI coding agent sources its vulnerability data.

Why NIST’s Triage Model Breaks Legacy Scanners

Under the new risk-based approach, NVD will prioritize full enrichment only for CVEs in CISA’s Known Exploited Vulnerabilities (KEV) Catalog (targeting one business day), CVEs affecting software used within the U.S. federal government, and CVEs for critical software as defined by Executive Order 14028. Everything else drops into “Lowest Priority — not scheduled for immediate enrichment.”

Do the coverage math the way Snyk framed it: 48,185 unique CVEs were published in 2025 according to Jerry Gamblin’s year-end review, while CISA’s KEV catalog added roughly 245 new entries by the end of 2025 per Cyble’s tracking. A scanner tuned to fully enriched NVD data is now, in effect, a scanner tuned to a government-priority shortlist. The vast open source universe your services actually depend on — the transitive npm package three levels deep, the abandoned Python library still shimmed into your ETL job — sits in the untriaged pile.

If you’re a fintech running a nightly SCA scan that pulls CVSS vectors straight from NVD, this means your severity dashboard tomorrow is not measuring the same thing it measured last quarter. “High” and “Critical” counts will drift not because your risk changed, but because the enrichment source did. My prediction: within twelve months, at least one high-profile breach post-mortem will name “reliance on unenriched NVD data” as a contributing factor, and boards will start asking vendors which sources actually feed their scoring.

What the CVSS Handoff to CNAs Actually Means

Buried in the NIST announcement is a change with bigger downstream consequences than the triage itself. NIST will no longer routinely provide a separate severity score when the submitting CVE Numbering Authority — the vendor or maintainer — has already supplied one. And modified CVEs will only be reanalyzed if NIST is aware of a change that materially impacts enrichment data.

On paper, this looks like sensible deduplication. In practice, it hands the CVSS pen to the same organizations whose products are being scored. There are now more than 500 independent CNAs, per the Snyk analysis, ranging from disciplined security teams at major cloud providers to overworked maintainers of single-purpose packages. Their scoring incentives are not uniform. A vendor with an SLA clock ticking has structural reasons to prefer a lower score. A maintainer under pressure from a bug bounty program has reasons to prefer a higher one.

Picture a healthcare platform team wiring vulnerability feeds into their compliance workflow — the kind of stack we build for regulated customers in our healthcare software practice. Under the old model, a NIST-provided CVSS acted as an independent second opinion. Under the new one, the vendor’s number is often the only public number. My take: independent second-opinion scoring just became a paid feature of commercial intelligence platforms, not a public good.

Why AI-Generated Vulnerability Reports Are Making Everything Worse

Snyk points the finger squarely at AI as the core catalyst behind the CVE explosion, and it’s hard to argue. Automated discovery tools can scan codebases and produce thousands of raw vulnerability reports in a fraction of the time human researchers need. Combine that with the federated CVE model — decentralized since 2018, now with 500+ CNAs — and you get exactly the flood NIST couldn’t drain.

Here’s the catch Snyk flags from its own maintainer experience: AI-generated reports frequently contain incomplete analysis, duplicates, and noise that don’t survive maintainer review. That means the incoming volume isn’t just larger, it’s noisier. A CVE ID no longer implies a validated finding — it implies someone, possibly an automated agent, filed a report that got a number. If you’re using an AI coding agent to auto-remediate dependencies (a workflow we help customers design in AI agent projects), that agent needs a curated intelligence layer between it and the raw CVE stream. Otherwise it will happily open PRs to “fix” issues that were rejected by maintainers weeks ago.

Concretely: if your team runs a Dependabot-style workflow that fires on any new CVE affecting a locked package, you’re about to get more pull requests at lower signal quality. My prediction: within twelve months, “CVE reputation” will emerge as a first-class metric — a confidence score attached to each advisory based on reporter track record, maintainer acceptance, and cross-source corroboration.

How Multi-Source Intelligence Becomes the New Baseline

Snyk’s argument, unsurprisingly self-serving but also structurally correct, is that vulnerability intelligence now has to be multi-source by default. The company describes an enrichment stack that combines in-house security research, threat intelligence signals like exploit activity and PoC publication, community disclosures, academic collaborations, and AI-assisted workflows validated by human analysts. Where relevant, Snyk publishes NVD’s CVSS vector alongside its own so users can see how sources diverge.

Why this matters practically: a single-source model made sense when submissions were manageable and enrichment was universal. Neither is true anymore. If you’re a supply-chain-heavy company — the kind of environment we tackle in logistics and traceability platforms — you need to know not just that a CVE exists but which package version, which code path, and whether a fix is shipping. Snyk calls this precise vulnerability mapping, and it’s the only way to keep alert fatigue from swallowing an engineering team once the raw signal doubles again.

Imagine you’re an AppSec lead at a mid-size SaaS. Yesterday, one dashboard number told you your risk posture. Tomorrow, you’re going to need at least three enrichment sources feeding a reconciliation layer, plus a policy for which source wins when they disagree. Most security teams don’t have that process yet. My take: the winners over the next two years will be the platforms that make source disagreement visible rather than hiding it behind a single averaged score.

FAQ

Q: What changed with the NVD on April 15, 2026? A: NIST announced a prioritized triage model, stating that full enrichment of every CVE is no longer a realistic goal. Only CVEs in CISA’s KEV catalog, those affecting U.S. federal software, or those covered by Executive Order 14028 critical software criteria will get full enrichment. Everything else is deprioritized, and historical CVEs published before March 1, 2026 have largely been reclassified as “Not Scheduled.”

Q: Why is CVE volume exploding now? A: Two forces are compounding. The federated CVE model, decentralized in 2018, now has more than 500 CNAs publishing disclosures directly, and AI-driven discovery tools can produce thousands of raw reports in the time a human researcher needs for a handful. Submissions grew 263% from about 18,000 in 2020 to more than 48,000 in 2025, per NIST’s own figures.

Q: Should I stop trusting NVD data entirely? A: No — NVD remains an important public reference, especially for CVEs that meet the new priority criteria. But treating it as your sole enrichment source now creates blind spots, particularly on CVSS scores for lower-priority CVEs and on reanalysis of modified entries. Multi-source intelligence, with visible source attribution, is the new floor.

Key Takeaways

• Audit your scanner today to identify how much of its severity data comes directly from NVD enrichment — if the answer is “most,” you have a coverage gap forming right now.
• Expect CVSS scores on non-priority CVEs to increasingly come from CNAs with their own incentives; build a policy for when to trust vendor-supplied scores versus independent validation.
• AI coding agents that auto-remediate need a curated intelligence layer, not raw CVE feeds — plan for a reputation or confidence signal on each advisory before wiring agents to production dependency graphs.
• Alert fatigue will worsen before it improves; precise vulnerability mapping down to package version and code path is the only way to keep alert noise from burying real risk.
• The next major AppSec breach post-mortem is likely to cite single-source vulnerability intelligence as a contributing factor — raise it with your board and auditors before they do.