Yesterday's headlines have sent ripples through the cybersecurity and software supply chain communities: MITRE announced that U.S. government funding for the CVE (Common Vulnerabilities and Exposures) database was set to expire today. Overnight, the CVE Foundation emerged with a plan to maintain the program before the Cybersecurity and Infrastructure Security Agency (CISA) announced it has extended support for the program this morning. As the backbone of the global vulnerability identification system, CVE has long served as the industry’s shared language for describing digital flaws. For Sonatype customers, here’s the good news: you’re already covered. Our security research and vulnerability dataset were built for this exact kind of disruption — and go far beyond CVE.
Its potential sudden disappearance should concern everyone in the industry. To be clear — this is not a surprise, but the industry at large has unfortunately grown to be systemically dependent on a single resource that was never built for the scale and speed of modern software development. For years, the CVE program has been the shared language of vulnerability management — allowing researchers, vendors, defenders, and developers to speak in consistent terms about flaws in code.
Without proper funding, vulnerabilities will be cataloged even more slowly, security tools that rely on CVEs could become less effective and threat intelligence sharing across the global cybersecurity community would suffer.
CVE: A vulnerability dictionary, but not without its limits
The CVE program is a standardized system for identifying and naming publicly known cybersecurity vulnerabilities. When a security flaw is discovered in software, it can be submitted for review. If accepted, the issue is assigned a unique CVE identifier (like CVE-2025-XXXX), along with a short description of the vulnerability. While the CVE itself doesn't include detailed technical data, exploit code, or patch information, it acts as the central naming authority. The goal is to provide a "common language" for tracking and sharing vulnerability information across the globe.
But it has also been under-resourced, slow to respond, and increasingly incomplete. In short: essential, but brittle.
Centralized CVE systems don't scale with decentralized risk
The unfortunate truth is that the CVE program has been slow to assign IDs, inconsistent in quality, and often missing critical details needed to take action. The CPE (Common Platform Enumeration) system used by CVE lacks the precision to reliably identify which components were truly affected. In fact, we've found that 92% of crowdsourced or publicly available vulnerability data needed a correction once detailed security research took place.
The CVE program was born in a very different time. The open source ecosystem was smaller. The software supply chain wasn't yet an intricate supply web. Vulnerabilities were disclosed manually, slowly, and often through vendor-controlled channels. That world is gone.
Over the past decade, CVE reports have grown exponentially, making it hard for publishers to keep up. Without support, the delay in addressing CVEs will only grow, exposing organizations to risk.
Today, open source projects are updated in real time, often with little or no centralized oversight. Disclosures happen on GitHub, Reddit, Discord, mailing lists, changelogs, Slack channels, or not at all. Expecting a single authority — especially one reliant on public funding cycles — to catalog everything is not just unrealistic, it's dangerous.
Evolving beyond a single source
At Sonatype, we've never been solely dependent on CVEs. We've built our entire approach to vulnerability intelligence around the reality that the CVE system, while foundational, is not infallible. For years, our customers have asked why we often refer to some vulnerabilities with our own Sonatype IDs instead of CVE numbers. Today, that question answers itself.
We didn't just find gaps in the CVE system — we found entire classes of vulnerabilities that never made it into CVE in the first place. So we built our own vulnerability research program. We created the Sonatype ID (SONATYPE-XXX) system to assign identifiers to security issues missed or delayed by CVE. We developed the infrastructure to scan changelogs, monitor GitHub activity, parse advisories, and evaluate fixes independently of any central authority.
This was never about duplicating CVE — it was about recognizing that the speed and sprawl of modern software requires intelligence gathering that is decentralized, real-time, and context-rich. We still use CVE IDs when available — but our mission has never been to mirror someone else's data. It's to protect our customers as quickly and accurately as possible, regardless of where that data originates. Our approach is simple: don't wait for someone else to tell you there’s a problem. Discover it yourself. Validate it. Notify your users.
So, yes, the CVE funding crisis is a real problem for the broader ecosystem. Many tools, vendors, and services built on top of CVE will now face a reckoning: what happens when your single source of truth goes dark? At Sonatype: our data pipelines are intact. Our intelligence is flowing. Our customers are covered.
The road ahead
We recognize this event means a lot of uncertainty and risk for the broader vulnerability management landscape. Without a universally accepted naming convention, it's likely that different vendors would assign different IDs to the same issues.
For Sonatype, our core mission has not changed. We will continue to discover, research, and inform customers of vulnerabilities in their software dependencies. Thankfully, we're not dependent on CVE to keep our intelligence flowing, because we architected around that limitation years ago. We saw where things were going and acted — now, more than ever, that decision proves its worth.
If you want to hear more about the shortcomings of a centralized system and recommendations for other approaches, I'm chatting with Ilkka Turunen, Sonatype's Field CTO, and Christopher "CRob" Robinson, Chief Security Architect at OpenSSF, about this on Tuesday at 9am ET — you can register here.
Stay safe. Stay secure. Stay ahead.
.jpg?width=150&height=150&name=fox-2016-1-sq%20(1).jpg)
Brian Fox, CTO and co-founder of Sonatype, is a Governing Board Member for the Open Source Security Foundation (OpenSSF), a Governing Board Member for the Fintech Open Source Foundation (FINOS), a member of the Monetary Authority of Singapore Cyber and Technology Resilience Experts (CTREX) Panel, a ...
Explore All Posts by Brian Fox
Discover a Better Way to SCA
Forrester evaluated 10 SCA providers and recognized Sonatype with the highest possible scores. Learn why Sonatype was named a leader in Forrester Wave™ for SCA.