Application security (AppSec) would not have existed for the past 25 years without the Common Vulnerabilities and Exposures (CVEs), the numbering system used for identifying discovered vulnerabilities in software. After the creation and adoption of the system in 1999, major companies such as Microsoft quickly began contributing CVE discoveries, using the Common Vulnerability Scoring System (CVSS) to convey the severity of a flaw.
Today, the software industry still relies on CVEs to reactively secure their products. Take, for example, the November 2021 discovery of Log4Shell (CVE-2021-44228), a remote code execution flaw in the Java logging framework Log4j that is still being exploited by threat actors today.
Despite the continuing relevance of this system, cracks emerged in the National Vulnerability Database (NVD) in 2024 as a result of a weak and centralized reporting structure, limited public funding, a lack of automation, and a growing pipeline of discovered flaws not yet accounted for. This led the National Institute of Standards and Technology (NIST) to cease enrichment of CVE records on the NVD.
Here's the chain of events that stifled the NVD in 2024, the immense impact of that change on the software industry, and how organizations should adjust their software security strategies as a result.
[ Download: 2025 Software Supply Chain Security Report | See the SSCS Report Webinar ]
No enrichment means vulnerability management suffers
Enrichment of CVEs refers to adding information such as Common Platform Enumerations (CPEs), Common Weakness Enumerations (CWEs), and CVSS scores to discovered vulnerabilities so that AppSec teams can use a standardized way of identifying, categorizing, and assessing various security flaws. NIST’s announcement that it would cease enrichment efforts meant that any CVEs disclosed between February and May of 2024 would lack this critical information.
As a result of this massive shift, a backlog of thousands of CVE reports quickly emerged. The 2025 Software Supply Chain Security Report from ReversingLabs analyzed this shift’s impact. As can be seen in the chart below, the number of CVEs analyzed for enrichment by the NVD steadily decreased at the start of 2024, and continued to drop.
Because NIST could no longer afford to enrich newly submitted CVEs, nongovernmental CVE numbering authorities (CNAs) were forced to pick up this growing backlog in 2024. ReversingLabs' annual report on the state of software supply chain security includes reporting on the impact of this change of responsibility from the NVD to CNAs.
Looking specifically at CVEs linked to open source code hosted on public repositories such as npm and the Python Package Index (PyPI), this massive shift in CVE enrichment ownership is clear. For npm packages related to CVEs, ReversingLabs found that the number of critical-, high-, and medium-severity CVEs added to the NVD declined by 74% from 2023 to 2024, while CNA-assigned and -enriched CVEs exploded from just a single reported CVE in 2023 to 172 in 2024.
Analysis of CVE-related packages on PyPI told a similar story: NVD-assigned and -enriched CVEs dropped by 74%, while CNA-assigned and -enriched CVEs with critical-, high-, or medium-severity ratings jumped from just three linked to PyPI packages in 2023 to 274 in 2024.
This major gap in enrichment was further confirmed by the firm VulnCheck, which estimated that 93% of new vulnerabilities received between 2023 and 2024 (open source or not) were not analyzed by the NVD — a gaping window for would-be threat actors.
CISA's Vulnrichment comes to the rescue
In the wake of chaos and uncertainty following NIST’s decision to cease enrichment of newly discovered vulnerabilities, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) stepped up to the challenge. The agency announced in May 2024 that it would begin a new program known as “Vulnrichment,” which aims to fill the gap caused by the massive shift of responsibility to CNAs this past year.
CISA’s Vulnrichment can be found on GitHub, and it serves to continually update CVEs with CVSS scores and other enrichment information in order to help the security community tackle newly disclosed software flaws. At the time of the program’s release, CISA shared its reasoning behind Vulnrichment on LinkedIn:
"We understand that timely and accurate information about Common Vulnerabilities and Exposures (CVEs) is critical to help organizations prioritize remediation, understand trends, and drive vendors to address classes of vulnerability.”
But while the move from CISA to help AppSec teams get a hold on vulnerability management is notable, it doesn’t negate the serious software supply chain security gaps that security practitioners may miss if they focus exclusively on CVEs. It’s often said that two things can be true at the same time. This applies to vulnerability management because, despite the NVD and CVE system being essential, they are also inherently flawed because they are a reactionary approach.
Get proactive — and think beyond vulnerabilities
Because modern vulnerability management relies on working from discoveries of flaws, security practitioners are likely to scramble to catch up on everything that needs to be patched. While they are doing that, security teams are likely not investing time and energy into taking proactive security measures that can spot software supply chain security threats before they become reality.
AppSec teams trying to figure out how to go about security despite the massive changes with the NVD should consider investing in efforts that will broaden their ability to find all kinds of software supply chain security threats — not just exploitable vulnerabilities.
A new study adds force to the argument to shift from a vulnerability-centric approach. The study, by a Purdue University researcher, shows that the newer Exploit Prediction Scoring System (EPSS), which many organizations are now using to prioritize vulnerability remediation given the NVD/CVE's decline, is not as effective as previously assumed.
The study demonstrates that, like other vulnerability risk-assessment frameworks, the EPSS is useful but is not a completely predictive mechanism for protecting against vulnerability-related threats.
By using a modern software supply chain security solution that harnesses the power of binary analysis and reproducible builds, AppSec teams instead focus on actionable information such as active malware, software tampering, secrets exposure, and more. These tools allow organizations to become proactive and better manage risk in an age of increasingly complex software.
Learn more with RL's 2025 Software Supply Chain Security Report, including why you team needs to shift beyond vulnerabilities — and get proactive on software risk with modern AppSec tooling.
