The Future of CVEs
Recent funding concerns have highlighted the need for a more resilient system of vulnerability identification.
Michael Lieberman
Ben Cotton
April 28, 2025
The security community was shocked earlier this month when funding for the CVE program was almost cut abruptly. Thankfully, funding was quickly restored for another 11 months. There’s no guarantee of funding beyond that point, so we should view this as an opportunity to consider changes to the CVE program. The CVE system has served the community well for 25 years, but the software landscape has changed. Open source software now dominates the industry, and new software contains many times more dependencies than software produced at the turn of the millennium.
Why CVE matters
The purpose of the CVE system is simple: to assign unique identifiers to known vulnerabilities in software and hardware. This allows everyone in the ecosystem to speak a common language. A vendor can say their update fixes CVE-2025-24813 and customers know that this is a bug in Apache Tomcat’s path equivalence evaluation, not some other Tomcat bug.
CVE information is pretty sparse. The CVE entry, when assigned, only contains an identifier, description, and creation date. Additional enrichment happens downstream in databases like the National Vulnerability Database (NVD) run by the United States’s National Institute of Standards and Technology (NIST). NIST and other downstream databases add information like affected release versions, severity scores, and other information that helps you understand, prioritize, and remediate vulnerabilities in your applications. None of this can happen without the base identifier to tie back to.
Flaws in the CVE program
The almost-loss of funding highlighted one key issue with the CVE program: centralization. The CVE program relies on the U.S. federal government providing funding to a private company to administer the program. While this arrangement has worked for a quarter of a century, that’s no guarantee that it will continue to work in the future. As priorities and geopolitical relationships change, vesting this responsibility with any single government poses a risk.
In addition, the Cambrian explosion in software, further driven by generative AI, creates an ever-increasing burden on the system. Sometimes CVEs are approved that are questionable or even entirely incorrect. This diminishes trust in the system and creates extra work for open source maintainers.
The creation of CVE Numbering Authorities (CNAs) a decade ago helps to mitigate these flaws. It allows companies and open source communities to become the authoritative source for issuing CVEs for their products and projects. This both eases the load on the central CVE system (and provides some short-term continuity should the central system fail) but it also means the people who understand the code the best are in a position to decide if a reported vulnerability is truly a vulnerability.
A look toward the future
The newly-announced CVE Foundation is worth watching. It’s a newly-formed non-profit led by some members of the CVE Board with a goal of creating an independent organization to manage the CVE program. By drawing from a diverse funding base, this foundation aims to avoid the single-point-of-failure risk in the current system. It’s too soon to see what will come of this, but if it can provide a vendor-neutral source of stability the way Linux Foundation and others have done for open source software, that’s a benefit to the ecosystem. When industry can help support this resource, we’re less dependent on government funding.
Another effort we’re watching is the Global CVE (GCVE) Allocation System in the European Union. GCVE is interesting because it doesn’t assign numbers to CNAs from a shared pool. Instead, it adds a field in the identifier for the GCVE numbering authority (GNA). Any current or future CVE can be easily expressed as a GCVE because the CVE program is GNA 0. So CVE-2025-24813 would be GCVE-0-2025-24813. If the Apache Software Foundation were assigned GNA 95, they could issue future Tomcat vulnerabilities as GCVE-95-YYYY-XXXXX. This ability to easily map historical vulnerabilities to the new system is compelling. However, if not everyone adopts it, future vulnerabilities may need both a CVE and a GCVE.
The OpenSSF and OWASP are also cooperating on a framework for a global platform for vulnerability reporting. This is still in draft form, but the focus is on a global, federated system. Any future direction for the CVE system needs to have a broad base of support. After all, what makes the CVE system work is the fact that everyone uses it.
Like what you read? Share it with others.
.webp)
.webp)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.jpg)
Previous
No older posts
Next
No newer posts
Want to learn more about Kusari?