NIST No Longer Enriching CVEs, Signaling Industry-Wide Shift Away from NVD.

The NVD changes eliminate CVSS as the single source of truth for many SCA vendors, making reachability essential for prioritization and vulnerability management.

April 29th, 2026

On April 15th, NIST announced major changes in how the National Vulnerability Database (NVD) manages enrichment, citing inability to keep up with a significant increase in CVE submissions. The NVD will effectively end enrichment support for most open source software vulnerabilities with nearly 300,000 backlogged CVEs published before March 1, 2026 being moved into "Not Scheduled" wholesale.

This has repercussions for the entire SCA market, especially in a world where Anthropic’s Claude Mythos and other models are expected to accelerate vulnerability disclosure to unprecedented levels.

Where now, vulnerability management?

Most vendors are transparent in their docs about their dependence on NVD. Their published severity methodologies will often directly mention that vulnerability severity is determined primarily by the CVSS score in the NVD. This, in turn, becomes the basis of prioritization in vulnerability management programs.

NVD enrichment provided many benefits to downstream SCA tools:

  • A Common Platform Enumeration (CPE) that standardizes information on version ranges to flag for what’s impacted.

  • An authoritative CVSS that functions as the primary prioritization tool of most organizations.

  • A Common Weakness Enumeration (CWE) that allows researchers to correlate findings to attack vectors. 

  • Normalized reference URLs that help speed up security responses.

For tools built on NVD intake, the changes mean that a CVE is now a mere description and an ID with no information about severity or exploitability. The CPE field sits empty or is wrong, so version matching would fail. Furthermore, the CVSS score now comes from whatever was self-reported by the CVE Numbering Authority (CNA), often the vendor of the buggy software itself, with commercial incentive to score it lower.

Semgrep made a different bet years ago

Since traditional SCA was oriented around matching vulnerabilities with an organization’s inventory of dependencies, NVD data proved sufficient.

But Semgrep Supply Chain was built for prioritization. We pioneered reachability in the SCA space, which required a different kind of data source: one that was specific to open source vulnerabilities, and had the right kind of metadata conducive to Semgrep’s static analysis. We needed to aggregate vulnerabilities both from GitHub repositories and package managers; we needed the inclusion of non-CVE entries, precise dependency mapping, and detailed patch information. 

So we chose GitHub Security Advisories (GHSA) instead of NVD as our underlying source of truth.

What security leaders should do this quarter

First, audit your compliance language. If your FedRAMP package, PCI DSS attestation, customer security questionnaires, or cyber insurance application reference "NVD CVSS score" as the source of truth, those documents need updating before someone asks where the score actually came from. 

Second, move prioritization off raw CVSS. Known Exploited Vulnerabilities (KEV) plus EPSS plus reachability is now the floor of a defensible program. Without an authority in charge of standardizing and validating submissions, a CNA-assigned CVSS is no longer reliable. 

Third, when the SCA contract comes up, ask the vendor where their data comes from after the NVD changes. Are their CVSS scores CNA-assigned or independently calculated? Ask how deep their reachability runs? Analysis can be dependency-level, function-level, or dataflow-level deep, each with vastly different implications for noise reduction, and thus vulnerability management in general.

Looking Ahead

The recent update from NVD presents an opportunity for security and vulnerability management teams to enhance their strategies. Organizations can adopt a reachability-based approach to minimize friction with development teams, filter out non-critical CVE noise, and demonstrably reduce their actual real-world risk.

The future of AppSec will be characterized by deep context, and impact-based prioritization. We’re excited that a foundational bet placed early in our growth now positions us to help you navigate this transition towards building a more secure, scalable future. To see Semgrep in action, you can check out a live demo.