March 16, 2026 was the date the current CVE contract expired. Thanks to some reporting by Cynthia Brumfield we learned there is a future funding plan for the CVE program. It’s a very opaque funding program which means we’re not sure how much, or how long, or anything useful really. We’ll have to watch the CVE program closely going forward to see if there are any hiccups. But regardless we have averted a potential emergency.

Now that the emergency is behind us, it’s a good time to step back and see what the state of vulnerability identifiers is, and what we should expect in the future.

The loss of trust

Let’s spend a few minutes talking about what happened over the last few years, and why it has eroded trust in the existing system. CVE the identifier probably won’t ever go away, but I think it now has a trust issue that will take a lot of hard work to recover from.

In 2024 we saw the NVD just sort of stop working without any real notice or resolution. NVD still hasn’t returned to a fully functioning state. NVD has historically been a source for vulnerability severities and affected products and projects. The data was never perfect and we loved to complain about it, but we certainly missed it when it was gone.

Then in 2025 we saw the CVE program almost lose its funding. This was a wake up call for a lot of the people in the vulnerability universe. Without a functioning CVE program, was there a plan B? There wasn’t for many of us. We just sort of assumed CVE was a staple of the vulnerability universe. Something that will always exist.

I think the takeaway from all the chaos in the last few years is that everyone should have a plan B.

The next steps

After the 2025 funding hiccup from CVE, there have been a lot of groups in the vulnerability community that have been working hard on how to make sure no matter what happens in 2026 (right now), they could find vulnerability data.

We saw the European Union Vulnerability Database (EUVD) go public and start to publish data. This project hasn’t been without some hiccups, but it’s clear the EU is looking to take vulnerability data seriously.

We saw the Global CVE (GCVE) program which is run by the Computer Incident Response Center Luxembourg (CIRCL) make some incredible strides. This is the project to keep an eye on if you’re wondering what a well run vulnerability data looks like.

There are also some really impressive open source vulnerability data projects like the GitHub Advisory Database and Google’s Open Source Vulnerability (OSV) service. Back when nobody knew what was going to happen to CVE, finding new and stable sources of data was a top priority, these two were at the top of everyone’s list.

Fragmentation?

A point often discussed once we start to talk about other vulnerability data sources is that fragmentation is generally bad for an industry. It’s probably worth pointing out that a lack of competition is usually worse than fragmentation. The CVE program has a storied history of not listening to the community and often providing substandard data and services. It’s likely a total lack of competition helped build this unfortunate reality.

However, fragmenting the vulnerability identifiers ecosystem is something that happened a long time ago. Even with CVE IDs, the data NVD provides was different from the data CVE provided. GitHub has advisories that don’t have CVEs. Most large vendors publish their own advisories that use their own naming scheme. These vendor advisories sometimes refer to CVE IDs, but not always.

The companies providing private curated vulnerability datasets are also a source of fragmentation. The CVE ecosystem fragmented a long time ago, what we need now is some good competition to help push everyone forward.

What is Anchore doing?

For the past year, Anchore has been preparing itself for a possible disruption in CVE vulnerability data. We were planning for the worst and hoping for the best. At the moment it looks like we got something closer to “best” than “worst”. This work is really about providing better overall vulnerability data, so CVE existing or not doesn’t really change the outcome. The goal is to make sure Anchore Enterprise and Grype can return high quality vulnerability information.

All CVE and NVD data is proxied and enriched by Anchore

There was once a time Anchore’s products would download the NVD data directly and turn it into a local vulnerability database. This is no longer the case. Anchore tracks our enriched CVEs in a GitHub repo we call Vulnerability Index Spec Files (naming things is hard). This is where we track our enriched CVE data that is used by Anchore Enterprise and Grype. We can update this data as we see fit, build new databases, and push them out very quickly now.

Anchore will be working with the community for data

Even if CVE continues working as before, it’s no secret that the CVE vulnerability data isn’t the best. There is an entire industry that has popped up just to fix all the problems in the CVE data. Anchore is not interested in trying to be a vulnerability data provider. This isn’t a business we want to be a part of. Even our public vulnerability data isn’t something we wanted to do, but we had to have a way to enrich CVE data and fill in all the gaps.

As the year progresses and we learn more about what will happen with CVE and all the other data sources, Anchore will ensure we will help the community any way we can. Finding and helping groups that are using tried and true methods of open source with vulnerability data is a top priority.

We can’t say for sure what comes next, but no matter what happens, it’s probably going to be interesting, and at Anchore we will not only try to help, but we know Anchore Enterprise and Grype will keep working as if nothing happened.