The CVE Program’s Close Call
In April 2025, the cybersecurity industry faced a near-crisis. The U.S. Cybersecurity and Infrastructure Security Agency (CISA) announced that its contract with MITRE Corporation, the organisation responsible for managing the Common Vulnerabilities and Exposures (CVE) Program, was set to expire on April 16.
For over 25 years, CVE has been a standardised, universal language for publicly disclosed vulnerabilities, serving as the backbone of global vulnerability coordination.The prospect of MITRE’s contract lapsing sparked immediate and widespread concern.
Just hours before the deadline, CISA extended MITRE’s contract for 11 months, narrowly avoiding an immediate shutdown. But this stopgap fix exposed a deeper fragility: the global cybersecurity community has placed enormous reliance on a single, government-funded entity to maintain one of the most critical components of its security infrastructure.
A Foundation Built On Shaky Bround
In response to the scare, members of the CVE board announced the formation of the CVE Foundation, a nonprofit organisation that aims to provide long-term sustainability, independence, and more diverse funding for the CVE program. Its mission is to protect vulnerability intelligence from political fluctuations and foster broader global participation.
This initiative couldn’t have come at a more urgent time. The National Institute of Standards and Technology's (NIST) National Vulnerability Database (NVD), which gives context to CVE entries with severity scores and metadata, has faced significant backlogs. As of late 2024, more than 20,000 CVEs awaited analysis, and only 47.9% of newly published vulnerabilities had been enriched with data like CVSS scores. This backlog leaves organisations without the critical content required to prioritise risks, slowing down response and fix times across the board.
Worryingly, even the scores that do exist can be misleading. JFrog’s Software Supply Chain State of the Union 2025 report found that 88% of ‘critical’ and 57% of ‘high’ CVEs were downgraded in severity after deeper analysis, indicating that CVSS scores often overstate the real-world risk to specific systems.
Vulnerability Volume Is Outpacing Software Growth
The volume of reported vulnerabilities is increasing rapidly. Our report also revealed 33,000+ CVEs were published in 2024, a 27% year-over-year increase, outpacing the 24.5% growth in open-source package adoption. More software equals more risk, yet our systems for identifying and responding to that risk haven’t scaled in tandem.
Meanwhile, alternative vulnerability tracking systems are typically specific to individual software projects or organizations. Vulnerability tracking identifiers like GitHub Security Advisories (GHSA), Python’s PYSEC, and Amazon Linux Security Advisories (ALAS) lack comprehensive coverage or consistency. For example, 41% of known Python vulnerabilities in the JFrog database have no corresponding PYSEC ID, creating blind spots for developers relying on a single vulnerability tracking source.
Fragile Practices & Widening Attack Surfaces
At the organisational level, practices haven’t kept up with risk exposure. In 2024, JFrog found that the average organisation ingested 38 new open-source packages per month - over 450 annually, yet 71% still allow developers to fetch packages directly from the internet, opening the door to supply chain attacks.
Despite increasing tool adoption (73% of organisations use seven or more security tools), key best practices remain missing. Binary-level scanning and secret detection are often overlooked, with JFrog alone detecting over 6,700 active secrets in public registries in 2024, a 64% increase over the previous year.
What comes after CVEs?
To build real resilience, the cybersecurity community needs to evolve beyond legacy models. A modern vulnerability management approach should include:
- Multi-source threat intelligence: Organisations should draw security data from multiple sources, including CNAs’ CVE data, GitHub security advisories, OSV, software vendor advisories, and internal telemetry, not just CVE and NVD. A single source is no longer sufficient.
- Applicability-aware analysis: Not all CVEs are relevant in every environment. JFrog research shows that 64% of high-profile CVEs had near-zero applicability in customer environments. This calls for tools that consider exploitability and actual reachability of vulnerable code.
- Guardrails on open-source use: Implementing proxy repositories and artifact managers helps vet packages before they’re integrated into builds, reducing exposure to malicious or vulnerable components.
- Contextual analysis & automation: Static CVSS scores miss the mark. Tools must go deeper, using code analysis, runtime behaviour, and environment awareness to assign risk. JFrog’s tools, for example, combine proprietary scanners and contextual enrichment to improve triage.
Preparing For The Inevitable
The near-loss of MITRE’s CVE stewardship serves as an industry-wide wake-up call. If that foundational system had collapsed, the shockwaves would’ve been felt across DevSecOps pipelines, compliance frameworks, and incident response workflows globally.
As software development accelerates, especially with the advent of AI-generated code, our vulnerability management strategies must evolve accordingly. The future demands a decentralised, resilient, and context-rich vulnerability intelligence infrastructure. That includes supporting nonprofit initiatives like the CVE Foundation, improving collaboration across ecosystems, and investing in smarter, more adaptive tooling.
Only by recognising and addressing the structural weaknesses in today’s vulnerability coordination model can we hope to prevent the next crisis, not just delay it.
Jonathan Sar Shalom is Director of Threat Research at JFrog
Image:
You Might Also Read:
