On April 15, NIST quietly reshaped the vulnerability landscape by announcing a prioritized enrichment model for the National Vulnerability Database. While most CVEs will still be published, the days of automatic CVSS scores, CPE mappings, and CWE classifications—the backbone of container scanning and compliance—are over for the majority of entries. This shift formalizes a trend that security teams have felt for two years: NVD is no longer the universal source of truth for every vulnerability. For container security programs that built pipelines around NVD as the authoritative secondary layer, this is a pivotal moment. Here are seven critical reassessments your team needs to make.
1. The Shift from Full Coverage to Prioritized Enrichment
NIST's move abandons the historic promise of enrichering every CVE with standardized metadata. Instead, only a select subset will receive the full treatment—CVSS scores, CPE product mappings, and CWE classifications. The rest are tagged as “Not Scheduled.” This means container scanners relying on NVD enrichment to auto-prioritize vulnerabilities will now face a gap. For example, a critical CVE in a popular container base image might lack CVSS data, forcing your team to manually assess or rely on vendors’ scores. This change formalizes a long-visible trend: NVD is no longer a complete, real-time feed. Programs must adapt by diversifying enrichment sources or building internal scoring logic.
2. Three Exceptions That Still Get Full Treatment
NIST carved out three categories that will continue to receive rapid, comprehensive enrichment: CVEs in CISA’s Known Exploited Vulnerabilities catalog (targeted within one business day), CVEs affecting software used by the federal government, and those tied to “critical software” as defined by Executive Order 14028. For container security teams running workloads in government contexts—or using software like container runtimes that might qualify—these exceptions provide a lifeline. However, this list is narrow. The vast majority of container vulnerabilities, especially in open-source libraries or niche tools, fall outside these categories. Teams should map their software inventory against these criteria to identify which CVEs will automatically get NVD support and which will require alternative approaches.
3. The 'Not Scheduled' Pile: A New Normal
All CVEs that do not meet the three exceptions are moved to a “Not Scheduled” status. This includes every unenriched CVE published before March 1, 2026—a massive retroactive reclassification. Organizations can request enrichment by emailing nvd@nist.gov, but no service-level agreement applies. In practice, this means the NVD backlog is unlikely to shrink for non-critical issues. Container security teams must understand that “Not Scheduled” does not mean low risk. A vulnerability in a container orchestration plugin could be actively exploited but lack enrichment. This new status demands a shift from passive consumption of NVD data to proactive, multi-source threat intelligence gathering.
4. Why Requesting Enrichment is a Workaround, Not a Solution
NIST invites requests via email, but with no timeline guarantee, this is not a scalable fix for container security programs processing hundreds or thousands of CVEs daily. Manual email submissions cannot keep pace with automated scanning pipelines. Moreover, the request process offers no transparency on prioritization or turnaround. For mature DevOps security teams, leaning on this channel would introduce unacceptable latency. Instead, consider alternative enrichment sources: vendor-supplied advisories, open-source databases like OSV.dev, or commercial threat feeds. Some container registries now include CVSS scores from multiple sources. Building a fallback layer that aggregates enrichment from various providers can help fill the gaps left by NVD’s selective coverage.
5. The Data Behind the Decision: CVE Explosion
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. This surge stems from more CNAs, more open-source projects running their own disclosure processes, and tooling surfacing issues that previously went unrecorded. For container security, this means the volume of vulnerability alerts is skyrocketing, even as NVD’s enrichment capacity shrinks. The implication: your container scanner may report more CVEs than ever, but with less contextual data to prioritize them. Teams must recalibrate their risk scoring—moving from relying solely on NVD’s CVSS to incorporating exploitability metadata, reachability analysis within containers, and business impact context.
6. Rethinking Vulnerability Scanning Dependencies
Container scanners have long assumed NVD would provide CVSS and CPE for every CVE. That assumption is now broken. Many scanners fall back to NVD enrichment, and when it’s missing, they may show incomplete results or assign default low confidence. This can lead to both false negatives (missing real risks) and false positives (wasting time on unenriched CVEs that are harmless in your context). Security teams should audit their scanning toolchain: Which enrichment sources are used? Are there fallbacks? Can the tool ingest CVSS from multiple CNAs? Some container registries and image analysis tools already offer built-in multi-source enrichment. Updating configuration to prefer vendor-provided scores or using a vulnerability intelligence platform can restore lost signal.
7. Adapting Your SLA and Prioritization Workflows
Service-level agreements (SLAs) for patching vulnerabilities often tie deadlines to CVSS severity. If CVSS is missing for a significant fraction of CVEs, your SLA enforcement becomes ambiguous. For instance, a “critical” CVE in NVD might have a patch SLA of 72 hours, but without a score, does it default to “medium” or trigger manual review? Container security programs need to update policies: define how unenriched CVEs are to be treated—perhaps requiring a manual risk assessment within the same patch window. Additionally, adjust prioritization models to weigh exploit intelligence, attack surface, and business criticality over CVE metadata alone. This change is an opportunity to move beyond NVD dependency toward a richer, faster vulnerability management strategy.
In conclusion, NIST’s announcement is not a disaster—it’s a catalyst. Container security teams that relied blindly on NVD enrichment now have a clear mandate to diversify their data sources, refine their scoring logic, and automate manual fallbacks. The organizations that adapt quickly will build more resilient vulnerability management programs. The ones that wait for NIST to return to full coverage will be left managing blind spots. Start reassessing today: map your software inventory to the three enrichment categories, audit your scanner’s fallback behavior, and implement multi-source enrichment. The container ecosystem’s security posture depends on moving beyond the assumption that NVD is the single source of truth.