Preparing for the Global Vulnerability Database

The near-death experience of the CVE Program (aka “MITRE”) last week was a huge wakeup call for the international vulnerability management ecosystem; this is because what was at stake with CVE.org’s problems was far worse than what’s at stake with the National Vulnerability Database (NVD)’s problems in the past year. The NVD is the biggest user of data from the CVE Program, but the consequences of losing CVE itself would be far larger.

What is most interesting is that just about everyone seems to be drawing the same two conclusions from this episode:

First, the current US-centric CVE/NVD vulnerability management program needs to be replaced with a truly international program, in which no one country or government plays a predominant role; and

Second, there is no point in even talking about creating a single huge database that includes all vulnerabilities of all types and all software products of all types. While that idea has a lot of intellectual appeal, it requires there be a single vulnerability identifier that can encompass all vulnerabilities, as well as a single software identifier that can encompass all types of software. It will be a long time – if ever – before either of those two dreams is realized.

This is why the ideas that are now being discussed for a new vulnerability management program to replace CVE.org and the NVD all focus on the idea of a federation of existing databases, linked by an intelligent querying infrastructure. This would have been hard to put together even ten years ago, but today – especially given the prevalence of AI – it doesn’t sound hard at all.

The idea of federation is especially appealing when you consider the huge cost of trying to unify all the world’s existing vulnerability databases into one uber database and, even worse, the cost of updating all that information in real time. It’s much better to let the staff members of each individual database continue to update their database using the sources and methods they’ve built up over the years; the federated structure will do its best to make it possible to query across all those databases, and receive as unified a response as is possible in this less-than-ideal world in which we live.

So, where do we go from here – i.e., what path do we need to follow to reach the common goal of a global federated vulnerability database, as well as a global federated vulnerability identification program? I saw two proposals at the end of last week.

The first proposal was articulated by Steve Springett, Chair of the OWASP CycloneDX project and Vice Chair of the OWASP Global Board of Directors (he emphasized in a conversation on Friday that the proposal as from the OWASP Board, not just himself). In the document, Steve emphasizes that the threats facing the software community today are quite different from what they were more than two decades ago, when the CVE Program and the NVD were in their infancy.

Steve especially points to vulnerabilities found in open source software, which was also in its infancy two decades ago but now is found (as components) in at least 90% of all software produced today. Steve also points to other relatively new threats, including cryptographic weaknesses and cybersecurity issues with AI. Steve concludes by saying:

We are calling on governments, industry leaders, researchers, and community experts to contribute their voices, expertise, and resources. Together, we can build an alternative model that complements existing efforts, gradually replacing outdated approaches with a federated, community-driven, and international standard.

The future of cybersecurity identification depends on global collaboration. Let’s build it together.

If you want to be kept informed about this initiative, send an email to cve@owasp.org. I will certainly participate in this.

A second proposal is from Olle Johansson of Sweden, who is also an OWASP member and a member of the OWASP SBOM Forum (as is Steve). Olle is suggesting a somewhat different approach: first describe the organization that will be needed to build and manage “a global platform for vulnerability reporting”, including what will be the roles of the different players in the vulnerability management ecosystem, including national governments, commercial software suppliers, open source projects, and software end users. He points out that only after we have figured all of this out will we be able to start filling in the technical details of the project. Olle is inviting interested parties to edit and comment on his proposal, which is a Google Doc.

A third proposal is from…me. While I’ve been writing for more than a year about the need for what I call the Global Vulnerability Database (GVD) – my most recent post on this subject is here – I’ve always thought of this as a project that’s waiting for its time to come.

Well, it seems its time has come, so here’s my proposal: While I agree that both Steve’s and Olle’s proposals need to be pursued, I also think we need to start talking about technical issues. I don’t mean the minute issues like whether EPSS scores should be included in CVE Records, but the more general issues that there’s been a lot of talk about, but no resolution.

A perfect example of this is version ranges. Everyone agrees this is an important issue, but nobody agrees on what to do about it. It is a fact that a vulnerability almost always affects a range of versions of a product, not just a single version. The biggest problem with version ranges is, as far as I know, there are no vulnerability management tools on the end user side that can ingest a version range in a CVE Record and then, for example, go to an asset management database and mark every version in the range as vulnerable.

Could this problem be solved if we made version range, not an individual version, the default in a software identifier like CPE or purl? That might make it easier to write the code on the end user side.

In any case, this is just one example of issues I would like to see addressed now, even though there are larger issues like Steve’s and Olle’s that need to be addressed as well. Fortunately, I already have a venue where we can have these discussions: the weekly meetings of the OWASP Vulnerability Database Working Group, which is a part of the OWASP SBOM Forum.

The VDWG meets biweekly on Tuesdays at 11AM Eastern Time. If you would like to join our next meeting on April 29 (where we’ll start to discuss the version range question), please email me and I’ll send you the series invitation (if you would like to join the SBOM Forum’s meetings, they’re also biweekly, but at 1PM ET on Fridays. Let me know if you would like that invitation as well). 

Don’t forget to donate! To produce these blog posts, I rely on support from people like you. If you appreciate my posts, please make that known by donating here. Any amount is welcome!

If you would like to comment on what you have read here, I would love to hear from you. Please email me at tom@tomalrich.com.

My book "Introduction to SBOM and VEX" is available in paperback and Kindle versions! For background on the book and the link to order it, see this post.