NIST Narrows the NVD for Container Security

NIST is limiting NVD enrichment, forcing container security teams to rethink scoring, CPE matching, and compliance evidence.

On April 15, 2026, NIST said it will no longer try to enrich every CVE in the National Vulnerability Database. The agency now plans to prioritize a smaller set of records, even as CVE volume keeps climbing and container teams still depend on NVD data for severity and package matching.

The change matters because container security programs often treat NVD as the second layer of truth after CVE publication. That assumption is getting weaker, and Docker’s warning is simple: if your scanners, SLAs, or audit packets depend on full NVD enrichment, it is time to check what happens when that enrichment never arrives.

What NIST changed, in plain English

NIST is still publishing most CVEs, but fewer records will get the extra work that security tools rely on: CVSS scores, CPE mappings, and CWE classifications. Three groups still get full enrichment quickly: CVEs in CISA’s Known Exploited Vulnerabilities catalog, CVEs affecting software used by the federal government, and CVEs affecting “critical software” under Executive Order 14028.

Everything else now lands in a new “Not Scheduled” bucket unless someone asks for enrichment by email. That request path exists, but it does not come with a service-level promise. NIST also stopped duplicating CVSS scores when the CNA already provides one, which trims work but also makes the database less of a universal scoring source than it used to be.

This is less a surprise than a formal admission. The drift has been visible for two years to anyone watching NVD feed delays, but the April announcement removed the last excuse to assume the old model would return.

The volume problem is real, and it is getting worse

The numbers in the article tell the story better than any policy memo. NIST said CVE submissions rose 263% from 2020 to 2025, while Q1 2026 was already running about one-third above the same quarter a year earlier. That is a brutal math problem for a database that still has to enrich records by hand.

FIRST’s FIRST forecast puts the pressure in context. The CVE ecosystem is producing more records because more CNAs exist, more open source projects run their own disclosure programs, and more tooling uncovers issues that would have stayed hidden years ago.

“Death by a thousand slops.”

Daniel Stenberg, curl founder, on AI-generated bug bounty reports

That quote from curl founder Daniel Stenberg captures the other side of the problem. AI is adding noise to vulnerability intake, while some AI systems are also finding real bugs at scale. The result is a pipeline with more volume, more junk, and more pressure on every review queue between disclosure and remediation.

Docker’s article points to both sides of that pressure. Stenberg shut down curl’s HackerOne bounty after six and a half years because the reports were becoming unmanageable. At the same time, Anthropic said its Claude research found thousands of zero-days across major operating systems and browsers, including a 17-year-old unauthenticated RCE in FreeBSD’s NFS server.

• curl closed its HackerOne bounty after 6.5 years because AI spam overwhelmed triage.
• Anthropic said Claude Mythos Preview found thousands of zero-days across major platforms.
• Docker notes NIST enriched about 42,000 CVEs in 2025, yet still fell behind incoming volume.
• FIRST’s 2026 forecast lands near 59,500 CVEs, which keeps the gap wide open.

Why compliance teams should care now

Container security is where this policy change gets operational. Many programs use NVD scores and CPE mappings to decide whether a package in an image is affected, how severe it is, and when remediation must happen. If a CVE has no enrichment, some scanners will show UNKNOWN severity or miss the package match altogether.

That creates a documentation problem as much as a technical one. FedRAMP, PCI-DSS 4.0, NIST SP 800-53, and SOC 2 do not all depend on NVD in the same way, but every one of them expects a defensible severity story. If your evidence chain says “we waited for NVD,” that chain is getting weaker.

• FedRAMP uses NVD CVSSv3 as an original risk rating, with fallbacks allowed.
• PCI DSS 4.0 references CVSS in external scan requirements.
• NIST SP 800-53 mentions NVD as an example source, not the only source.
• DORA and SOC 2 are principles-based, so teams still need written severity rationale.

The practical question is simple: if NVD stops scoring a CVE, what does your program do next? Mature teams already have fallback rules in their SSPs, risk registers, and exception processes. Teams that do not may discover the gap during the next audit instead of during the next patch cycle.

Where container images feel the impact first

Docker is right to focus on containers, because images amplify every weakness in vulnerability data. A container image inherits packages from its base layer, dependencies from the application, and transitive packages from both. If one of those packages has a CVE without NVD enrichment, the issue can disappear from a scanner that depends too heavily on CPE or CVSS from NVD.

That is where vendor architecture starts to matter. Some tools only read NVD and a narrow set of feeds. Others combine multiple advisory sources and match on package URLs, which keeps identification working even when CPE strings are missing.

Docker says its Docker Scout layer pulls from 22 advisory sources, including NVD, CISA KEV, EPSS, the GitHub Advisory Database, and 13 Linux distribution security trackers. It also matches on PURLs instead of relying only on CPE, which is a better fit for modern container inventories.

The company’s Docker Hardened Images package adds another layer: signed build attestations, SBOMs in CycloneDX and SPDX, OpenVEX exploitability statements, and scan results. Docker says those SBOMs come from a SLSA Build Level 3 pipeline, so the package list does not depend on NVD being complete.

That matters because remediation can now be driven by the image itself, not by waiting for an external database to catch up. Docker also says its Hardened System Packages allow package-level patching without waiting on a distribution maintainer’s release rhythm.

What teams should check in their own stack

If your program still assumes NVD will fill every gap, the next review cycle should include a few direct questions. What sources sit behind your scanner besides NVD? What happens when a CVE has no CVSS score? Does that finding still trigger a ticket, a SLA clock, or a manual review?

Also ask where your remediation timer starts. Some teams measure from CVE disclosure, others from NVD enrichment, and that difference will matter more now that enrichment is no longer guaranteed. If your written policy does not say which date counts, the auditor may choose the stricter reading.

Docker’s article also makes one more operational point worth keeping in mind: older, unenriched CVEs published before March 1, 2026 have already been moved to “Not Scheduled.” That means old findings in your tracker may still show severity labels that no longer match the live NVD record.

For teams buying container security tools, the procurement question is straightforward. Is NVD one input among many, or is it the main source of truth? The answer matters more now because the database is not shrinking, but its role is.

Bottom line for container security programs

NIST has made the shift explicit, and container teams should treat that as a cue to audit their data sources, scoring rules, and fallback policies now rather than later. If your vulnerability workflow still depends on NVD as the primary source of severity and package matching, expect more exceptions, more manual triage, and more audit questions.

The best next step is practical: test a handful of recent CVEs with missing enrichment, trace how your scanner handles them, and compare that result with your written policy. If the policy and the tool do different things, fix the policy first so the next board review is about evidence, not surprise.