A Global Vulnerability Database

 

…consistency is the hobgoblin of little minds.

- Emerson

Whenever you identify problems in an existing organization, program or device, you always face the question: Will it be easier to fix what is currently in place, rather than have to start over from scratch? Or will it be easier – or at least better – to start from scratch and build something of your own design, which hopefully avoids all the problems with the existing system?

Early in 2022, I got together a group of people who were committed to making SBOMs successful, but were concerned that this will never happen unless certain obstacles are removed from their path; we call ourselves the SBOM Forum. I knew there were a number of problems to address (including maybe 4 or 5 “showstoppers”), but I wasn’t terribly concerned about which one we started with – as long as we started somewhere.

However, there was one thing I was sure of: I didn’t want us to start with the “naming problem” – that is, the problem that a single software product can have many different names in different contexts, and these names can correspond to subtle (or not-so-subtle) differences in the product (small code variations, source code vs. compiled binaries, etc.). It seemed to me that, if we started with the naming problem, we’d work on it for five years and still be no closer to solving it than we were when we started.

But I didn’t want to constrain the conversations we had in our weekly meetings, so I let them go in whatever direction people wanted to take them. Guess what topic we ended up focusing on within a couple of weeks? You’re right…the naming problem. So much for planning, eh?

However, I was surprised by how much progress we made when we started discussing the naming problem. There are many aspects to the problem, but the one that’s probably on the minds of most people in the software security community is the National Vulnerability Database (NVD), which is by far the most heavily used vulnerability database worldwide. The NVD’s biggest problem is the software identifier it uses: CPE.

As we started discussing these problems, I was amazed that a) the problems became easy to identify and describe (I had thought it would take a year just to describe the problem we were addressing), and b) the solutions became apparent very quickly, at least at a high level (I’ll admit we had deployed a secret weapon that greatly speeded up identification of the solutions: Steve Springett, leader of the CycloneDX and Dependency Track projects and someone who – from what his family tells me – never goes to bed unless he’s solved at least one software security problem that day).

The result was that, five months after we started discussing the subject, we published a paper that has received a good amount of attention. It described what we saw as the major problems with CPE, as well as the broad outlines of a solution to the problem. Early this year, we started talking with Tanya Brewer, leader of NIST’s NVD team, about implementing our solution. She said they had read our paper with interest and would like to collaborate with us (as well as a few other organizations that have reached out and offered to help them).

These three posts - first, second, and third – described our conversations with Tanya. In the third post, I relayed the news that NIST would soon come out with a video asking for suggestions on a public-private partnership to fix the problems (as well as accomplish other goals, to be sure), and they would probably post a Federal Register notice about their plans in late August. Tanya thought the PPP could be up and running by early 2024.

How is that coming? Well, it’s now about six weeks after the date Tanya said she’d have the video out and…there’s been no word at all. This means the whole schedule is probably pushed back two months already…and counting.

What happened? I know they were having a serious problem that might have required “all hands on deck” (the last time we talked to her, her head count was down about 20%, since she hadn’t even begun to receive her 2023 funds – this was in late June. Of course, given that the US almost defaulted on its debt a few weeks earlier, I guess this isn’t a huge problem in the scheme of things), although the notification about that serious problem has been removed from their website, as well as the admonition not to ask them when it would be fixed. I also know that the video was first delayed by a couple of weeks because somebody who had to sign off on it was on vacation (does NASA work the same way? “Sorry, we’ll have to postpone the moon launch for ten months since Mr. Smith has to have surgery, and nobody else has authority to sign for him”).

Of course, delays like this are par for the course in the government game, and we haven’t given up on the NVD; we’ll pick up the phone whenever they want to talk. However, we’ve now decided that it’s time to work on Plan B, which is a Global Vulnerability Database.

Why have we moved from Plan A to Plan B? Because B has always been our goal. The whole world is becoming more and more concerned about software vulnerabilities.  We’re sure there will be a lot of interest in Europe, the UK and Japan (and perhaps other countries like Singapore), both in the public and private sectors, in having a single, robust global vulnerability database. In fact, we’ll have a first meeting with ENISA next week.

Given the upcoming (although still not finally approved) EU Cyber Resilience Act, as well as the rapid growth of SBOM use among software developers (plus the fact that SBOM use by organizations whose primary business isn’t software development has – to put it gently – nowhere to go but up. But it will go up, mark my words), it frankly makes no sense not to start mapping out a global vulnerability database.

The paper we put out last fall is no longer our wish list for the NVD (although we’d be glad to see it implemented at the NVD, bien sur), but rather the start of a blueprint for the GVD. Of course, we’re not going to walk away from the wealth of vulnerability information already in the NVD, namely the existing vulnerability listings. It’s easy to obtain; some organizations download the entire NVD multiple times a day, with time off for a leisurely lunch. And we’re not going to walk away from the CVE.org database, which is where the NVD’s vulnerability information ultimately comes from (in fact, one of the board members of CVE.org is a very active member of the SBOM Forum).

Fortunately, putting together this database doesn’t require solving any problem that hasn’t been solved hundreds or thousands of times already. And frankly, I think a lot of organizations worldwide feel a little guilty about never contributing to the NVD – which has never even asked anyone for money, as far as I know. I think the money to get the GVD up and running will be fairly easy to obtain.

Who will run the GVD long term? It could be a government body (although I’m not interested in trying to shake Washington for money, especially since there’s a good chance the government will be shut down through at least some of the fall. After all, shutting the US government down is becoming almost a pre-holiday tradition, like getting a Christmas tree) or even a private industry group. However, maybe the best long-term solution is IANA, which already assigns IP addresses and runs DNS. There are lots of options.

Any opinions expressed in this blog post are strictly mine and are not necessarily shared by any of the clients of Tom Alrich LLC. 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.