POST: CVEpocalypse

# Now that the dust has settled: Rethinking CVE after the defunding/refunding turmoil

The recent problem around MITRE's CVE.org first with its defunding, then a reversal (literally at the 11th hour) was more than just an admin contract hiccup. It did expose the deeper problems in the software vulnerability disclosure "ecosystem", including hyper centralization, complete dependence on the US federal government funding, and the fragility derived from these highlighting the lack of agility in how software vulnerability advisories are created or aggregated, distributed, shared, and consumed.

Now that the dust has settled, I want to look beyond the chatter and seriously reconsider how we can build a more resilient and decentralized model for vulnerability reporting, using existing open standards and minimal adjustments.

### What happened in April 2025?

MITRE's CVE.org program faced a funding crisis, leading almost to its shutdown, and then a reprieve, likely to be temporary. In mid-April 2025, we found out that the U.S. government's contract with MITRE to manage the CVE.org program was about to expire on April 16, 2025, with no a renewal in sight.

The possible shutdown of the CVE program raised many alarms in the security and vulnerability community, as CVE has a somewhat central role to track and inventory cataloging software vulnerabilities, centrally.

Possibly in response to the outcry, the U.S. CISA reverted back at the last minute, AND extended MITRE's CVE.org contract for 11 months.

Note that based on public records, that contract with is likely worth between 25 and 30 million USD per year. Not petty change for MITRE at any scale, that even with a multi-billion budget often deals with much smaller contracts.

The mini-crisis highlighted the brittleness of relying on a single entity funded by a single government for a important (or critical)piece of cybersecurity data source. There have been tons of discussions to establish something more sustainable and decentralized for vulnerability disclosure and sharing. When it is impossible to escape the word "resilience" when talking about cybersecurity these days, it became painfully clear that this CVE program was nowhere close to be resilient, but the writing has already been on the wall for a long while. For instance the related NIST's NVD, that takes its feeds from CVE.org to enrich them with severity rating has been structurally deficient and failing to process CVE records with a backlog of about 12 months and no process in sight to resolve this (which recently led to an audit of the NVD).

### The core problem

At its heart, the situation highlighted two main issues:

- Hyper-dependence on a single, centralized authority (CVE.org) to coordinated and publish vulnerability data.

- The fragility in vulnerability sharing processes, even among CNAs who already have the data, the capabilities, and the motivation to share it, but still rely on central aggregation.

Beyond, this issue and the NVD issues also brings forward the likely dysfunctional relationships between US Govt. agencies: NIST manages NVD, funded also in part by CISA, who pays MITRE to support CVE.org and CISA also publishes its own CVE enrichments and scoring, all of which look as competing, diverging, and chaotic efforts to yours truly, as an innocent bystander.

This looks truly FUBAR, so when a single funding hiccup can stop and destabilize an important part of a the global cybersecurity data infrastructure, it is time to decentralize!

### What does CVE.org actually do?

- It defines the specifications for CVE data, including the JSON schema used to structure vulnerability records, and maintains the CWE (Common Weakness Enumeration) taxonomy for classifying vulnerabilities.

- It anoints and manages a hierarchy of CVE Numbering Authorities (CNAs), who are responsible to identify and create CVE records, "numbering" them with a centrally defined range of CVE numbers assigned in non-overlapping blocks to each CNA by CVE.org.

- It aggregates CVE records from CNAs and publishes them centrally on CVE.org.

The first two functions are well-executed and quite important. These are neither time- nor funding-sensitive, and can withstand bumps in the road.

The vast majority of CVE records are created outside of CVE.org by a band of some 450+ CNAs. And the third function introduces a bad bottleneck: centralized aggregation and publication. This is where the system becomes fragile, as it creates a single choke point of failure resulting in potential delays in disseminating the vulnerability data. And when the funding runs out, that central choke points is a global liability. I am do not know what extra processing is done by CVE.org on CVE shared by CNAs. My hunch is that there is no extra processing done, because none is needed, but I have no inside info on that,

## Two emerging CVE.org alternatives: The CVE Foundation and GCVE

Two noteworthy alternative initiatives emerged from this mess and morass: The CVE Foundation at https://www.thecvefoundation.org and the Global CVE Ecosystem (GCVE) at https://gcve.eu/. Both are trying to provide more transparent, distributed and resilient structures and infrastructure to support the CVE system beyond the traditional U.S.-government-centric and -backed model.

The CVE Foundation is a group of CVE board members that wants to foster an independent stewardship for CVE, while GCVE works to provide a federated, globally coordinated network of CNAs and vulnerability data providers. These efforts, even if they look like knee jerk reactions, signal some momentum towards a more distributed future for vulnerability data, and one that aligns more closely with my vision for a decentralized future. Both are a clear sign that the community wants and needs to break free of the unhealthy shackles of hyper centralization and dependency on the CVE centralization,

### A path forward: decentralized vulnerability publishing with multiple aggregators

Instead of relying on a single clearinghouse, I want to consider a model where each CNA can *publish their advisories directly* and would be joining a federated system based on common formats and simple conventions.

And furthermore, why not expanding the 450 CNAs to 5,000, or 50,000, or 500,000?
After all, each responsible open source project and software vendor should be best positioned to determine when a software bug rises to be a security vulnerability. Projects should be in control and this could help avoid damaging and churn-generating vanity CVEs that are the bane of the current system.

One promising approach would be to adopt and extend **well-known URLs** and, in particular, the `/.well-known/security.txt` mechanism. This simple, standardized location already supports links to CSAF advisories, has been adopted by major actors in the space like RedHat, and could be trivially extended to include pointers to other formats beyond CSAF:

* CVE JSON-formatted vulnerability disclosures that are sent by CNAs to CVE.org
* OSV (Open Source Vulnerability) entries used by Google, GitHub and a few others
* SBOMs in CycloneDX or SPDX format (or KISSBOM ;) )
* VEX and VDR documents in existing standard format (CSAF, CycloneDX or OpenVEX)

This could further be minimally enhanced to specify how the same .well-known data folder could be included in the source code repository of an open source project, or in a container image, or in a software release source or binary archive. With this pointers to live, updated vulnerability data would be readily available directly from the source, with the code.

This could be critically useful for compliance. For instance the EU CRA requires to report upstream security bugs that you discover, and demands some active vulnerability management and processing. When you use 10,000 FOSS packages, being able to discover where to report a bug is going to be important. And being able to collect vulnerability and VEX reports about 10,000 packages will com handy.

### Why this can work

I think this approach can work because, it is:

* **Minimalist**: Adopt and minimally refine existing standards for well known URLs.
* **Decentralized**: Each CNA, each open source project, and each software vendor becomes a self-publishing node in a federated system.
* **Standardized**: It is based on existing, common formats and standards like CVE, CSAF, OSV, CycloneDX, and SPDX. There is plenty of existing tooling for these. And all use PURL of course! (or are about to)
* **Discoverable**: Well-known URLs and folders form a predictable way for humans and machines alike to find vulnerability data across organizations.
* **Resilient**: There is no single point of failure anymore; if one CNA goes dark, others remain unaffected. The whole CVE program can kill over, and we can still get vulnerabilities from each CNA and publishers.
* **Faster**: Direct publication can reduce delays and red tape.
* **Redundant**: CVE.org can stay as a privileged aggregator among many, but multiple aggregators can also efficiently provide redundant services with minimal efforts.

### TODO to get there

To make this work, we need:

* **Some community consensus** to extend the well-known `security.txt` spec to include references to CVEs, SBOMs and other related formats beyond CSAF. The success of PURL as a mostly universal software package identifier for software supply chain security workflows shows that it is possible to build and evolve global de-facto standards from grassroots community efforts, so it is worth trying!

* **Some tooling support** to automatically discover, validate, and aggregate these decentralized advisories from the many well-known places. Most of the tools and library already exists there that can parse CVE JSON and SBOMs. VulnerableCode and Vulnerability-Lookup are two well-known FOSS examples that show that this is doable.

* **Listings** of known "well-known" URL as indexes to help bootstrap multiple advisory aggregators. Note that all CNAs already publish their CVE records to CVE.org. A super simple improvement would be for all the CNAs to also publish the same records directly and advertize that feed location at a well-known URL. No changes needed for CVE.org. We do not even need to wait for a well-known schema or security.txt update: we can start doing it now and experiment and refine along the way.

And also, later:

* **Governance models** in a new world where CVE.org would be acting as an index and privileged aggregator, rather than a gatekeeper. I will leave this to organizations like the CVE Foundation, CVE.org and MITRE to figure out.

* **Incentives and guidance** to help CNAs adopt this pattern and not adding operational burden and costs, or at least minimize these. This would be a good way to direct some minimal cash to help bootstrap the process.

The CVE program remains important, but its recent instability shows that we cannot treat it as the only game in town. Let’s use this moment as an opportunity to rethink its foundations!

The idea of a single, centralized database of security bugs was awesome 25 years ago, but it has run its course.

A decentralized, federated, standards-driven future for vulnerability disclosure is not only possible, but also necessary to support the modern and fast moving software development efforts in a more secure and resilient way.

Let’s build it together :heart: