NIST NVD goes risk-based: which SCA tools still miss Deferred CVEs

TL;DR

---

NIST NVD changed its operations to keep up with the growing volume of CVEs.
Starting April 15, 2026, NVD no longer enriches every CVE with CVSS, CWE, and CPE at the same depth — it prioritizes those tied to real-world impact or U.S. government use.

This is not “NVD is shutting down.”
CVEs themselves are still added to NVD.
What changes is the treatment of the extra information (NVD enrichment) that NIST adds afterward.
If your vulnerability management tooling assumes NVD CPEs or NIST-side CVSS are present, you start to see gaps: a CVE exists but doesn’t link to your products, severity is missing, or re-analysis after a modification arrives late.

CVEs are still published, but enrichment is now prioritized

According to NIST’s announcement, CVE registrations grew 263% from 2020 to 2025.
NVD also enriched a record ~42,000 CVEs in 2025 (45% above the previous record), but inflow is outpacing the throughput gains.

The three new priorities:

Priority target	How to read it
CVEs added to CISA KEV	Already-exploited vulnerabilities. NIST targets enrichment within 1 business day of receipt
CVEs in software federally used by the U.S. government	Treated as higher impact for federal assets
CVEs in EO 14028 critical software	Foundational software touching privilege, networking, data control, and trust boundaries

Non-priority CVEs are marked “Lowest Priority - not scheduled for immediate enrichment” on NVD.
According to the NVD documentation, Not Scheduled corresponds to the Deferred status in the NVD API — outside the NVD scope, or not queued for enrichment due to resource constraints.
Users can still request enrichment individually, but the assumption that everything ends up in the queue automatically is gone.

The unenriched backlog from early 2024 is also being moved into Deferred for everything published to NVD before March 1, 2026.
The expectation that an old CVE will eventually pick up a CPE is now lower.

Query NVD API directly for vulnStatus

A single command tells you where a CVE sits in NVD via the NVD API v2.0.

curl -s 'https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-XXXX-XXXX' \
  | jq '.vulnerabilities[0].cve
        | {id, vulnStatus, lastModified,
           hasCpe: (.configurations|length > 0),
           hasCvssV31: (.metrics.cvssMetricV31|length > 0),
           hasCvssV40: (.metrics.cvssMetricV40|length > 0),
           hasCwe: (.weaknesses|length > 0)}'

vulnStatus will be one of:

Value	Meaning
Received	CVE description received; enrichment not started
Awaiting Analysis	In the enrichment queue
Undergoing Analysis	An NVD analyst is working on it
Analyzed	Enrichment complete
Modified	Description was modified after publication
Deferred	Enrichment is not scheduled (equivalent to Not Scheduled under the new operations)
Rejected	CVE itself is rejected

If hasCpe: false comes back, no CPE applicability statements are attached. If your SCA tool narrows down assets through CPE matching, that CVE drops out of detection.

Querying the past CVEs covered on this blog — Ollama’s CVE-2026-7482, and Dirty Frag-related CVE-2026-43284 and CVE-2026-43500 — in May 2026, all three come back with vulnStatus set to Analyzed or Modified, with CPE, CVSS, and CWE populated. KEV-aligned and kernel-tier software does get the priority treatment as advertised.

By contrast, CVE-2026-6584, published in late April 2026 (TransformerOptimus SuperAGI 0.0.14, authorization bypass), returns:

{
  "id": "CVE-2026-6584",
  "vulnStatus": "Deferred",
  "lastModified": "2026-04-29T01:00:01.613",
  "hasCpe": false,
  "hasCvssV31": true,
  "hasCvssV40": false,
  "hasCwe": true
}

The CVE exists on NVD, the CVSS v3.1 and CWE were attached by the CNA (not by NVD), but the CPE field stays empty. If your SCA tool matches assets by looking for cpe:2.3:a:transformeroptimus:superagi:* applicability on NVD, this CVE does not surface — even though it’s an authorization bypass in an AI agent framework.

With the bulk endpoint you can filter by vulnStatus=Deferred and run a periodic check to see whether your tracked CVEs are slipping into Deferred.

SCA tools rely on different sources

Dependency scanners and vulnerability management (VM) tools each carry their own database, or stitch together multiple sources. Even with NVD going risk-based, the actual impact depends on what your tool consumes upstream.

Tool	Primary data sources	NVD reliance
Snyk	Proprietary Snyk Vulnerability DB (ingests NVD, GHSA, ecosystem advisories, then re-analyzes)	Medium (overlays its own CVSS and impact range)
Trivy (Aqua)	trivy-db (aggregates NVD, GHSA, distro security trackers, ecosystem-specific advisories)	Medium–high (uses NVD CPE and distro advisories together for package matching)
Grype (Anchore)	NVD, GHSA, distro advisories	High (NVD CPE matching is at the core)
Dependabot (GitHub)	GitHub Advisory Database (GHSA)	Low (GHSA primary; CVE data from NVD is re-curated on GitHub’s side)
OSV-Scanner (Google)	OSV.dev (aggregates GHSA, PyPA, RustSec, Go vulndb, etc.)	Low (ecosystem-specific advisories take precedence)

Roughly: tools that ride on GHSA or OSV (Dependabot, OSV-Scanner) are less exposed to NVD enrichment delays. GHSA and OSV are run by separate teams and assign their own package mappings to CVEs. SCA products that re-analyze and maintain a proprietary DB — like Snyk — can also absorb NVD Deferred cases to some degree.

On the other side, tools centered on NVD CPE matching (Grype, NVD-direct VM products, in-house CVE pipelines that consume only NVD) end up with growing blind spots for non-priority CVEs. SuperAGI’s CVE-2026-6584 is exactly the kind of niche-OSS / AI-agent-framework CVE that falls into this gap.

The actual data source your vulnerability management depends on isn’t on the marketing page — check trivy-db update sources, Snyk’s Vulnerability Sources configuration, and Dependabot’s ecosystem-specific advisory feeds directly.

KEV is a strong signal but not the whole picture

CISA KEV — the list of CVEs confirmed to be actively exploited — is explicitly a priority target under the new NVD operations.
Already-exploited vulnerabilities should be prioritized over theoretical CVSS scores, and that’s a reasonable ordering.

But not-in-KEV does not mean safe to ignore.
KEV is a post-exploitation signal, so it lags right after zero-days, in narrow targeted attacks, and immediately after a researcher’s PoC drop.
And “silent patches” — where maintainers ship a security fix without filing a CVE — don’t even exist as CVEs in the first place, let alone in KEV.

The Aikido write-up (from a vendor selling vulnerability management) also notes that “fixes that never became CVEs never reach NVD either.”
The product pitch is mixed in, but the underlying point — you still need to mine changelogs and commit messages for silent patches — holds.

EUVD and SRP add more observation points

In response to NVD’s prioritization shift, EUVD emerges as an EU-side data source.
ENISA’s European Vulnerability Database, launched in May 2025, ties together CSIRTs, vendors, existing databases, and CISA KEV, and exposes mitigations and exploitation status. It is not a drop-in replacement for NVD; ENISA itself frames it as an interconnection layer across multiple sources.

From September 11, 2026, the Cyber Resilience Act also requires product manufacturers to report actual exploitation and severe incidents through the Single Reporting Platform (SRP). SRP is a reporting system for EU-market products and is separate from EUVD.

The era where NVD alone was the right answer is shifting toward one where KEV, GHSA, OSV, EUVD, and SRP each carry a different role.

Operational checklist

Given NVD is no longer “the single source that enriches every CVE evenly”:

• Identify what your SCA / VM tool consumes as a primary source (GHSA direct / OSV-routed / NVD direct / proprietary re-analysis)
• Don’t auto-drop CVEs with hasCpe: false as “not applicable.” Treat vulnStatus=Deferred as a flag to verify through another path
• Prioritize CISA KEV entries immediately, but don’t use “not in KEV” as a safety claim
• For critical OSS in your stack, follow GitHub Advisory, OSV, and vendor release notes through a separate channel
• EUVD is an additional observation point, not an NVD replacement. If you ship into the EU, also watch the SRP reporting requirement starting 2026-09-11
• Schedule a recurring job that hits the NVD API for your tracked CVEs and surfaces transitions into Deferred