NIST Narrows the NVD: What Container Security Programs Should Reassess

On April 15, NIST announced a prioritized enrichment model for the National Vulnerability Database. Most CVEs will still be published, but fewer will receive the CVSS scores, CPE mappings, and CWE classifications that container scanners and compliance programs have historically relied on.

The change formalizes a drift that has been visible to anyone pulling NVD feeds for the past two years. What shifted on April 15 is the expectation: NIST has now said plainly that it does not intend to return to full-coverage enrichment. For programs that built scanning, prioritization, and SLA workflows around the assumption that NVD sits as the authoritative secondary layer on top of CVE, that assumption is worth a structured review.

What changed

Three categories of CVEs will continue to receive full enrichment:

• CVEs in CISA’s Known Exploited Vulnerabilities catalog, targeted within one business day
• CVEs affecting software used within the federal government
• CVEs affecting “critical software” as defined by Executive Order 14028

Everything else moves to a new “Not Scheduled” status. Organizations can request enrichment by emailing nvd@nist.gov, though no service-level timeline applies. NIST has also stopped duplicating CVSS scores when the submitting CNA provides one, and all unenriched CVEs published before March 1, 2026 have been moved into “Not Scheduled.”

The NIST volumes behind the decision

NIST cited a 263% increase in CVE submissions between 2020 and 2025, with Q1 2026 running roughly a third higher than the same period a year earlier. The rise tracks with a broader expansion in CVE numbering: more CNAs, more open source projects running their own disclosure processes, and more tooling surfacing issues that would not have reached CVE a few years ago.

AI is a compounding factor on both sides of this curve. In January, curl founder Daniel Stenberg shut down the project’s HackerOne bug bounty after six and a half years, citing “death by a thousand slops”: AI-generated reports that read like real research but described vulnerabilities that didn’t exist. Node.js, Django, and others have tightened intake under similar pressure. On the signal side, Anthropic’s April announcement of Claude Mythos Preview described a model that autonomously discovered thousands of zero-day vulnerabilities across every major operating system and web browser, including a 17-year-old unauthenticated RCE in FreeBSD’s NFS server. Earlier Anthropic research documented Claude Opus 4.6 finding and validating more than 500 high-severity vulnerabilities in production open source.

More noise and more real signal are heading toward the same pipeline. NIST enriched roughly 42,000 CVEs in 2025, its highest annual total, and still fell further behind incoming volume.

How it lands in compliance

The operational question is what programs have to document when NVD scoring is not available, and how consistently that documentation holds up across assessments.

None of these frameworks break on their own. Mature vulnerability management programs generally have language in their SSPs and risk registers covering fallback scoring and exception handling. Programs that do not will likely need it before their next audit cycle.

The gap that is relevant to the container ecosystem

Two NVD inputs matter most for container scanning:

• CPE applicability statements map a CVE to specific software packages. When CPE strings are missing, a scanner that matches primarily on CPE cannot determine which packages in an image are affected. The CVE exists in the database but is operationally invisible to the scan.
• CVSS scores drive prioritization and SLA routing. Without a score, a CVE may surface as UNKNOWN severity or fall outside remediation workflows entirely.

Container images create a compounding effect here. Each image inherits packages from a base layer, application dependencies, and often a long transitive dependency chain. When any of those packages carries a CVE that NVD has not enriched, the gap propagates through every downstream image built on top of it. Scanners that draw on multiple advisory sources, and that match on package identifiers other than CPE, are less exposed.

Questions worth putting to image vendors

• What advisory sources does your tooling use beyond NVD?
• When a CVE has no NVD CVSS score, what does the tool display, and does it trigger remediation workflows?
• How do you define “patched,” and is that definition in your written CVE policy?
• Are your remediation SLAs measured from CVE disclosure date or NVD enrichment date?
• Can a third-party scanner reproduce your clean-scan result against public advisory data?

Where Docker sits

Docker Hardened Images are designed so that vulnerability management in container workloads does not depend primarily on NVD enrichment. Each image ships with signed attestations for build provenance, SBOMs in both CycloneDX and SPDX formats, OpenVEX exploitability statements, and scan results. SBOMs are generated from the SLSA Build Level 3 pipeline rather than inferred from external databases, so package inventory is accurate regardless of NVD’s enrichment state. Hardened System Packages allow package-level patching independent of upstream distribution timelines, which means remediation is not gated on a distribution maintainer’s release cadence or on an NVD analyst’s queue. When a CVE is not exploitable in a specific image context, that assessment is published as a signed VEX document that third-party scanners including Trivy, Grype, and Wiz consume natively.

Docker Scout, the scanning layer that reads these attestations, aggregates 22 advisory sources including NVD, CISA KEV, EPSS, GitHub Advisory Database, and 13 Linux distribution security trackers. Scout matches on Package URLs (PURLs) rather than NVD’s CPE scheme, which allows package identification to continue when CPE strings are unavailable. NVD remains a valuable input to this architecture, one of several rather than the spine.

What to reassess

Audit open findings against the March 1, 2026 cutoff. Any CVE published before that date that has not received NVD enrichment has already been moved to “Not Scheduled.” Programs carrying open findings tied to those CVEs may have severity scores and CPE mappings in their trackers that no longer reflect an active NVD record. Verify that the scoring basis for those findings is documented and defensible independent of NVD.

For programs running DHI, the NVD policy change does not require an operational response. For programs evaluating container security vendors more broadly, the question worth elevating in the next procurement cycle is whether NVD is one source of vulnerability intelligence in their stack, or the primary one.

The NVD will continue to play a role. That role is narrowing, and the signals suggest it will keep narrowing. Programs that use the April announcement as a prompt to audit their data sources now will have a cleaner answer the next time a regulator, an auditor, or a board asks where their vulnerability data actually comes from.

Sources and further reading

• NIST, “NIST Updates NVD Operations to Address Record CVE Growth,” April 15, 2026 https://www.nist.gov/news-events/news/2026/04/nist-updates-nvd-operations-address-record-cve-growth
• FIRST, “2026 CVE Vulnerability Forecast” https://www.first.org/blog/20260211-vulnerability-forecast-2026
• FedRAMP Vulnerability Scanning Requirements v3.0 https://www.fedramp.gov/docs/rev5/playbook/csp/continuous-monitoring/vulnerability-scanning/
• Docker Scout advisory database sources https://docs.docker.com/scout/deep-dive/advisory-db-sources/
• Docker Hardened Images documentation https://docs.docker.com/dhi/

• “Why We Chose the Harder Path: Docker Hardened Images, One Year Later”https://www.docker.com/blog/why-we-chose-the-harder-path-docker-hardened-images-one-year-later/