CVE circles the drain

When I wrote this post barely more than two weeks ago, it seemed to be like sounds of a faraway battle that might eventually start spilling into your region. You need to pay attention to those sounds, but you’ll get a lot more warnings before the battle starts to impact you directly. In other words, there’s no need to take your family and flee your home now. The army will protect you from the invaders; after all, look at that huge fort they’ve been building for years – it looks like it could withstand a two-year siege!

However, it seems I was wrong. Not only has the battle reached our region, but the fort was overwhelmed before it could even mount a defense – or before the defenders even knew they were in danger. In fact, it’s too late to even think about fleeing. We just have to stand silently as the victorious attackers parade through our streets and stare scornfully at their vanquished foes.

Perhaps I’m letting my metaphors carry me away a little, but this is without doubt a turning point in the vulnerability management timeline. After all, the first 300 or so CVEs were reported in 1999; last year, the total reached around 275,000. Moreover, the rate at which new CVEs are being identified is growing by leaps and bounds every year. As VulnCon showed two weeks ago, the cybersecurity community is increasingly coming to realize that software vulnerabilities are at the root of almost all the serious cybersecurity threats – e.g., ransomware – that we face. Vulnerabilities will never be eliminated, but they can certainly be managed.

Or so we hope.

Are we lost? After all, MITRE researchers came up with the idea for CVE in 1999 and MITRE has run the program to identify and document new CVEs since then – in fact, the CVE Program and the database it ran used to be called MITRE. Today, both the program and the database are called CVE.org. An independent board, consisting of public and private sector representatives, runs the CVE program. Funding for CVE.org now comes entirely from CISA (or at least it did).

It's hard to think that the CVE Program might stop dead in its tracks, yet when a contract is cancelled, that’s usually what happens. But don’t worry, we’ve been given plenty of notice. The contract expires tomorrow, April 16. We have almost 24 hours to continue to enjoy the fact that MITRE still breathes the same air we do!

But what comes on Thursday? I assume no more new CVE Records will be produced, although the existing CVE Records won’t go away. You’ll still be able to learn about many previously identified CVEs (although the serious problem I discussed in this post remains. In fact, the remedy I prescribed, implementing purl as an alternative identifier in the CVE Program, is even more important now).

Also keep in mind that there are other vulnerability types besides CVE, such as GitHub Security Advisories (GHSA) and OSV; they shouldn’t be affected by this at all. On the other hand, the 275,000 vulnerabilities in CVE.org dwarfs both of these databases, as well as the other open source security advisory databases that are mostly specific to particular ecosystems like Python. There’s no disguising the fact that the software vulnerability management universe is going to become very tightly constricted two days from today.

Fortunately, there has been ample warning that the current US government-centric system, including the National Vulnerability Database (NVD) and CVE.org, isn’t sustainable. After all, 14 months ago the NVD fell seriously behind in their self-assigned responsibility to produce CPE names and add them to CVE Records (which are, of course, produced by CVE.org. CVE is part of DHS, while the NVD is part of NIST, which is part of the Department of Commerce. I recommend you reread the beginning of this post, in which I described the two organizations). Not only has the NVD not made up the ground it lost, but it continues to lose more ground almost every day.

More than a year ago, I started talking about a Global Vulnerability Database; I have refined the idea, and I summarized it in this post 11 days ago. As you can see, the GVD won’t be a single database. Instead, it will be a federation of existing vulnerability databases (probably including the NVD and CVE.org).

I’m going to stop now; perhaps I’ll write one or two more posts on this topic this week. However, I’ve already made the decision that this Friday’s meeting of the OWASP SBOM Forum (held every other week at 1PM EDT) will be devoted entirely to this topic. In fact, we’ll probably keep doing that for a while – and we might form a separate project just to start discussing – and eventually implementing – the Global Vulnerability Database.

If you aren’t currently a member of the SBOM Forum and would like to join us this Friday and perhaps afterwards, please drop me an email.

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.