TL;DR: NIST’s shift to a risk-based CVE approach comes after backlog growth left many submissions unprocessed, creating gaps in enrichment, scoring, and downstream detection for teams that treat NVD as a source of truth, according to Aikido. The practical result is that vulnerability coverage now depends on multiple sources, not a single database.
NHIMG editorial — based on content published by Aikido: Reliable CVE sources in the age of NIST NVD cutbacks
By the numbers:
- By mid-2024, 75% of submitted CVEs were unprocessed.
- Despite a 45% increase in CVEs enriched in 2025, the CVE submissions increased by 263%.
- In its first year, 67% of packages where Intel found vulnerabilities were never publicly disclosed to any database.
Questions worth separating out
Q: How should security teams handle vulnerabilities that are missing from NVD?
A: They should not treat missing NVD data as evidence of safety.
Q: Why do central vulnerability databases create blind spots for AppSec teams?
A: Central databases can lag behind patches, miss undisclosed fixes, or prioritise only certain categories for enrichment.
Q: What do security teams get wrong about CVE coverage?
A: They often assume that if a risk matters, it will appear in a database and receive equal analysis.
Practitioner guidance
- Correlate at least three vulnerability sources Use NVD, package-level release intelligence, and an advisory feed or internal research process before suppressing or closing findings.
- Measure enrichment lag as a security metric Track the time between patch release, advisory publication, and visibility in your prioritisation workflow.
- Flag high-risk packages for manual validation Create a review path for internet-facing libraries, authentication components, and heavily used frameworks when the primary database has no entry but release notes indicate a fix.
What's in the full article
Aikido's full blog post covers the operational detail this post intentionally leaves for the source:
- Aikido Intel's package-monitoring workflow and how it cross-checks findings against multiple vulnerability databases
- The specific examples of packages with undisclosed vulnerabilities and the timing gap between patch release and CVE enrichment
- How the advisory publishing process works when no public disclosure exists yet
- The product-level implications of relying on Aikido Intel instead of a single central feed
👉 Read Aikido's analysis of NVD cutbacks and reliable CVE sources →
NVD backlog and false negatives: what security teams should change?
Explore further
Coverage gaps are now the normal operating condition, not an exception. The article shows that vulnerability intelligence can no longer be treated as a single authoritative feed. When enrichment and disclosure lag patching, security teams need to assume that unseen issues already exist in production. The practical conclusion is that modern vulnerability governance must combine database intelligence, package telemetry, and release-note monitoring.
A question worth separating out:
Q: What should organisations do when one vulnerability feed disagrees with another?
A: They should investigate the discrepancy rather than defaulting to the most familiar source. A disagreement may mean one feed is delayed, one advisory is unstructured, or one database has not yet mapped the issue. In a mature programme, discrepancies trigger validation, not closure.
👉 Read our full editorial: NVD cutbacks show why CVE enrichment is no longer enough