NIST is narrowing enrichment, not ending CVE publication#
NIST has changed the operating assumptions behind the National Vulnerability Database. On April 15, NIST announced a prioritized enrichment model for NVD. CVEs will still be published in most cases. What changes is the secondary data many security programs depend on: CVSS scores, CPE mappings, and CWE classifications.
That distinction matters. A CVE record can exist without being operationally useful to the same degree. For many scanners, compliance workflows, and remediation dashboards, the value comes not only from the CVE identifier, but from the enrichment around it. The score drives severity. The CPE mapping helps determine whether a product or package is affected. The weakness classification supports reporting and analysis.
Docker’s write-up argues that the April 15 announcement formalizes a drift that users of NVD feeds have already seen over the last two years. The more important change is expectation. NIST is no longer signaling a return to full-coverage enrichment.
Under the new model, three categories of CVEs will continue to receive full enrichment:
- CVEs listed in CISA’s Known Exploited Vulnerabilities catalog, targeted within one business day.
- CVEs affecting software used within the U.S. federal government.
- CVEs affecting “critical software” as defined by Executive Order 14028.
Other CVEs move to a “Not Scheduled” status. Organizations can request enrichment by emailing NVD, but Docker notes that no service-level timeline applies. NIST has also stopped duplicating CVSS scores when a submitting CNA already provides one. Unenriched CVEs published before March 1, 2026 have been moved into “Not Scheduled.”
For container security teams, the issue is not whether NVD remains useful. It does. The issue is whether internal programs still treat NVD enrichment as a guaranteed layer beneath scanning, prioritization, and audit evidence.
Why the backlog pressure is structural#
NIST cited a 263% increase in CVE submissions between 2020 and 2025. It also said Q1 2026 was running roughly one-third higher than the same period a year earlier. That growth tracks with a broader expansion of the CVE ecosystem: more CNAs, more open source projects with formal disclosure processes, and more tooling that surfaces issues which may not have received CVEs in earlier years.
The pipeline is also under pressure from two different directions.
One is noise. Docker points to curl founder Daniel Stenberg’s January decision to close the project’s HackerOne bug bounty after six and a half years, citing “death by a thousand slops”: AI-generated vulnerability reports that looked plausible but described issues that did not exist. Other projects, including Node.js and Django, have tightened intake under similar pressure.
The other is real signal. Docker cites Anthropic’s April announcement of Claude Mythos Preview, described as autonomously discovering thousands of zero-day vulnerabilities across major operating systems and web browsers, including a 17-year-old unauthenticated RCE in FreeBSD’s NFS server. Docker also references earlier Anthropic research in which Claude Opus 4.6 reportedly found and validated more than 500 high-severity vulnerabilities in production open source.
The point is not that every AI-generated finding is useful. It is that both weak reports and legitimate discoveries are increasing load on the same public vulnerability infrastructure. NIST reportedly enriched roughly 42,000 CVEs in 2025, its highest annual total, and still fell further behind incoming volume.
That makes the April 15 shift less surprising. It also makes it harder for organizations to treat missing enrichment as a temporary data-quality defect.
Where container scanners feel the change#
Two NVD enrichment fields are especially important in container scanning.
The first is CPE applicability. CPE statements help map a CVE to specific software products or packages. If those mappings are missing, scanners that depend primarily on CPE matching may not be able to determine whether a package inside an image is affected. The CVE may exist, but it can become functionally invisible to that scanning workflow.
The second is CVSS scoring. Scores drive severity labels, triage queues, and remediation SLAs. If a CVE has no NVD score, it may appear as UNKNOWN severity, inherit a vendor score, or fall outside established remediation logic depending on the tool and policy.
Containers amplify this problem. A single image can include an operating system base layer, system packages, application dependencies, language ecosystem packages, and long transitive dependency chains. If an unenriched CVE affects a package in a base image, the gap can propagate into every downstream image that inherits it.
The practical exposure depends on scanner design. Tools that rely on several advisory sources and match against package identifiers beyond CPE are less exposed than tools that treat NVD as the main authority. SBOM quality also matters. If inventory is inferred poorly, missing NVD enrichment compounds an already weak picture. If package inventory is accurate and tied to build provenance, teams have more room to reason about affected status even when NVD data is incomplete.
Compliance does not break, but audit evidence gets harder#
Docker’s article emphasizes the compliance angle: programs need to document what they do when NVD scoring is not available.
This is not the same as saying major frameworks collapse. They do not. Mature vulnerability management programs usually have fallback scoring language, exception handling, and risk-register procedures. But programs built around a simple “NVD score equals SLA” model may need updates before their next assessment cycle.
The exact impact varies by framework and assessor expectation. PCI DSS external scanning requirements reference CVSS, and ASV guidance points to NVD. That can create ambiguity for unscored findings. Other frameworks may use more permissive language, list NVD as an example source, or rely on principles-based severity rationale rather than a single database.
The operational question is simple: if NVD has no CVSS score, what severity does the organization assign, why, and can that rationale be applied consistently?
If the answer lives only in a scanner default setting, it is probably not enough. Security teams should make the fallback explicit in the system security plan, vulnerability management policy, risk register, or equivalent control documentation.
Questions to ask vendors and internal teams#
The most useful response is not panic. It is dependency review.
Container security teams should ask image vendors, scanner providers, and internal platform teams a few direct questions:
- What advisory sources are used beyond NVD?
- Does the scanner depend mainly on CPE, or can it match on package identifiers from other ecosystems?
- When a CVE has no NVD CVSS score, what severity is displayed?
- Do UNKNOWN or unscored findings trigger remediation workflows?
- Are remediation SLAs measured from CVE disclosure date, vendor advisory date, or NVD enrichment date?
- How is “patched” defined in written CVE policy?
- Can a third-party scanner reproduce a clean-scan result using public advisory data?
These questions expose whether the program is measuring vulnerability state or merely measuring NVD enrichment state.
Docker also uses the article to position Docker Hardened Images as less dependent on NVD enrichment. It says those images ship with signed attestations for build provenance, SBOMs in CycloneDX and SPDX formats, OpenVEX exploitability statements, and scan results. It also says SBOMs are generated from a SLSA Build Level 3 pipeline rather than inferred from external databases, and that Hardened System Packages allow package-level patching independent of upstream distribution timelines.
Those are vendor claims, but the underlying control pattern is sound: reduce reliance on a single enrichment source, improve package inventory, document exploitability context, and separate remediation evidence from one public queue.
Practical takeaways#
NVD is still important. But it is no longer safe to assume that every relevant CVE will receive timely NVD enrichment.
For container programs, the near-term work is concrete:
- Inventory where NVD CVSS and CPE fields drive scanning, dashboards, SLAs, and compliance reports.
- Define fallback severity logic for CVEs without NVD scores.
- Confirm that scanners use multiple advisory sources and package-aware matching.
- Treat UNKNOWN severity as a workflow state, not a place for findings to disappear.
- Update audit documentation before the next assessment, not during it.
The risk is not that vulnerability management becomes impossible. The risk is quieter: teams may keep running the same process while one of its core assumptions has changed underneath it.