In April 2025, the cybersecurity world had a collective heart attack. MITRE, the organization that has operated the Common Vulnerabilities and Exposures (CVE) program since 1999, announced that its contract with the U.S. government to fund the program was set to expire -- with no renewal in sight. For about 72 hours, the system that underpins essentially all vulnerability tracking on the planet looked like it might go dark.
It did not. Funding was extended at the last minute. But those 72 hours exposed something that many of us had been warning about for years: the CVE program has a single point of failure, and that point of failure is a government contract.
What Actually Happened
The timeline matters here because misinformation spread fast.
On April 15, MITRE sent a letter to CVE Board members warning that the contract funding the CVE program and the related CWE (Common Weakness Enumeration) program would expire on April 16. This was not a negotiating tactic or a budget placeholder -- the organization was genuinely preparing for the possibility of having to wind down operations.
The Cybersecurity and Infrastructure Security Agency (CISA), which manages the contract on behalf of the Department of Homeland Security, executed an 11-month extension on April 16, just before the deadline. Crisis averted, technically. But the damage to confidence was done.
Why This Matters More Than You Think
If you work in security, you already know why CVE matters. But let me spell it out for the people who make budget decisions.
Every vulnerability scanner, every security advisory, every SBOM vulnerability correlation, every compliance framework that references software vulnerabilities -- they all depend on CVE identifiers. When someone reports that a library has a security issue, the CVE ID is the canonical identifier that lets every tool in the ecosystem reference the same vulnerability unambiguously.
Without CVE:
- National vulnerability databases (NVD, which itself has been struggling with backlogs) lose their primary input
- Automated vulnerability scanners cannot correlate findings across tools
- SBOMs lose their connection to known vulnerability data
- Security advisories from vendors become harder to deduplicate and track
- Compliance frameworks that reference CVEs become unenforceable
The entire vulnerability management ecosystem is built on the assumption that CVE IDs exist and are maintained. That assumption almost broke.
The Structural Problem
The near-miss exposed a governance model that was designed for a different era. When MITRE started the CVE program in 1999, there were about 1,500 CVEs issued per year. In 2024, the number exceeded 40,000. The program grew by orders of magnitude, but the governance and funding model barely changed.
Here are the structural issues:
Single funder dependency. The entire program has been funded by one contract with one government agency. No commercial entity pays for CVE operations, despite the fact that the program generates enormous value for the private sector.
Volunteer CNA model at scale. CVE Numbering Authorities (CNAs) -- the organizations authorized to assign CVE IDs -- are largely volunteer operations. There are now over 300 CNAs, and coordination is increasingly difficult.
No clear succession plan. Until the funding crisis forced the conversation, there was no serious public discussion about what would happen if the U.S. government stopped funding the program.
NVD backlog compounding the problem. The National Vulnerability Database, which enriches CVE records with severity scores and other metadata, has been struggling with a massive backlog since early 2024. The CVE program's near-failure would have made an already bad situation catastrophic.
The CVE Foundation and What Comes Next
In response to the crisis, a group of CVE Board members announced the formation of the CVE Foundation, a nonprofit entity designed to provide an alternative governance and funding model for the program. This is a significant development, but it raises as many questions as it answers.
The foundation model could work. The Linux Foundation, the Apache Software Foundation, and similar organizations have demonstrated that critical open infrastructure can be sustained through broad-based industry funding. But those foundations were built over years, with careful governance design and strong organizational backing.
The CVE Foundation is being built in crisis mode. Key questions remain unanswered:
- How will the foundation's authority relate to MITRE's existing role?
- Which vendors will commit funding, and how much?
- Will the foundation have the technical infrastructure to operate the CVE system independently if needed?
- How will international stakeholders be represented?
The European Union's ENISA has also been building out its own vulnerability database, which could serve as a partial alternative. China and Japan maintain national vulnerability databases as well. The risk is fragmentation -- multiple competing vulnerability identification systems would be worse than a single imperfect one.
Lessons for the Industry
Lesson 1: Critical infrastructure needs resilient funding. Single-source government funding for critical shared infrastructure is a design flaw, not a feature. The security industry needs to step up and fund the systems it depends on.
Lesson 2: We need to decouple identification from enrichment. The CVE/NVD split -- where CVE handles identification and NVD handles enrichment -- made sense when volumes were low. At 40,000+ CVEs per year, the pipeline is bottlenecked at every stage. We need distributed, federated approaches.
Lesson 3: Tooling should be resilient to CVE disruption. Any security tool that breaks completely without CVE data has a single point of failure. Good tooling should be able to work with multiple vulnerability data sources and gracefully degrade when one source is unavailable.
Lesson 4: SBOMs become more important, not less. In a world where vulnerability databases might be fragmented or temporarily unavailable, having a complete, accurate inventory of what software you are running becomes even more critical. You cannot respond to a new vulnerability advisory -- regardless of what identifier it uses -- if you do not know what you have deployed.
How Safeguard.sh Helps
Safeguard.sh is built to work with vulnerability data from multiple sources, not just CVE/NVD. Our SBOM platform correlates vulnerabilities from CVE, OSV, GitHub Advisory Database, and vendor-specific sources, providing resilience against disruption in any single data source. Our policy gates can evaluate vulnerability data regardless of its origin, and our MCP Server gives your team real-time access to your vulnerability posture. The CVE crisis was a wake-up call -- Safeguard ensures you are prepared even if the next one does not resolve so quickly.