Tuesday, April 2, 2024

We all want to save the NVD, but what does that mean?

In the chat for last week’s OWASP SBOM Forum meeting, Dmitry Raidman of Cybeats asked me to point out to anyone attending the RSA Conference this year that Cybeats is sponsoring their third RSA SBOM Meetup at 6 PM on Monday. It is co-sponsored by Cybeats, CodeSecure, and VulnCheck. You can get more information on the meetup at https://lu.ma/rsa-sbom-meetup

Dmitriy also pointed out that there’s an AIBOM Workshop at RSA on Tuesday, run by volunteers Dmitry (Cybeats), Helen (SAP), and Daniel (Manifest) at SAP Labs. You can also join virtually. Here's the registration: https://lu.ma/AIBOM-workshop-RSAC2024 

The good news is that everyone involved in the discussion of what to do about the National Vulnerability Database’s current severe problems (including me) seems to agree that the NVD needs to be “saved”. The bad news is that “saving the NVD” means very different things to different people.  For the discussion to move forward, everyone needs to determine what they mean by this phrase. Here are the primary meanings that I’ve discerned in the discussions, as well as my opinions on their merits:

1. I just hope the NVD can get back to where it was before February, which was fine for me

A lot of people seem to fall into this camp. This is a natural reaction, given that a large number of organizations have built extensive vulnerability management practices based on the assumption that the NVD will always do what it did before the problems began on February 15; for a great description of those problems, I refer you to Vishal Garg’s recent post on LinkedIn. The NVD still hasn’t explained what happened, except for Tanya Brewer’s (the head of the NVD team at NIST) statement at VulnCon that the problem was just a “silly” government-caused issue.

While everybody is entitled to use their own judgment on this issue, I do want to point out that the perception that “everything was fine” before February 15 is clearly wrong. After all, if everything had been fine, how could a “silly government-caused issue” have had such a severe impact on the NVD, with the result that even today, over 45 days later, they’re still not much more than one-third recovered? More importantly, NVD is part of the government. Presumably, government-caused issues, whether silly or not, will recur frequently. Will the result be any different during these events in the future?

Moreover, the NVD has had severe problems for a long time. The biggest is the fact that the CPE identifiers on which the NVD is based are clearly inadequate, since so many searches for products in the NVD come up empty-handed, even when they’re based on a CPE name that in theory follows the spec. For some of the reasons why this is the case, see pages 4-6 of this document from 2022 by the OWASP SBOM Forum. It’s still quite relevant today – in fact even more so now.

2. The NVD has announced that it will form a Consortium to address its problems; I’ll wait to see how that works out.

This post describes how the Consortium idea came up: Early last year, the SBOM Forum started talking to the NVD (and specifically Tanya Brewer) regarding how we might help them address some of their problems, primarily the problems with CPE. Since outside organizations aren’t allowed to give direct advice to federal agencies (unless engaged as a consultant), Tanya came up with the Consortium idea after talking to the NIST lawyers about how this could be done legally.

She described this idea to us last May and said she was going to release a video explaining this to the public in June. However, after that she went silent on us, and the next we heard of the Consortium was when the notice appeared on the NVD website after the problems started in February. She briefly discussed it in her talk at VulnCon last week, and it sounded like what she had described to the Forum last year.

I don’t have a problem with the Consortium idea, but to describe this as in some way a solution to the NVD’s current problems is a joke. For one thing, there are several steps that need to be taken before the Consortium can even have a meeting. These include the following:

1.      The idea needs to be published in the Federal Registry.

2.      The NVD has to come up with a Letter of Intent, describing what they want the Consortium to do (the post linked above describes what Tanya told the SBOM Forum would be the main goal of the Consortium: to provide coders to help them fix their ancient software infrastructure. My guess is that a lot of forward-thinking organizations won’t be interested in this).

3.      Interested organizations need to apply to join the Consortium and be approved by NIST (no individuals or unincorporated organizations are eligible to join).

4.      At that point, each chosen organization will need to negotiate a Cooperative Research and Development Agreement (CRADA) with NIST. Each CRADA will describe how the organization and NIST will conduct their research and what are the desired outcomes. Note that “research” doesn’t usually mean “providing advice”.

5.      Only after all the organizations have finalized their CRADAs will the Consortium start working. And only then will the Consortium start to discuss what it will accomplish.

I am sure the above process will take at least six months and most likely longer – and that’s just to  get the Consortium to its first meeting. While I don’t think doing this would be a terrible idea, it’s clear the NVD’s problems can’t wait for six months to a year, at best.

3. I don’t want the data in the NVD to be lost

There’s no danger of that happening. The NVD isn’t big and can be downloaded in 10-15 minutes. Lots of companies download it multiple times a day. More importantly, there are a number of other databases that include all the data in the NVD and a lot more – including VulnCheck and VulDB. Most of these databases aren’t free, but any organization that has been seriously impacted by the NVD’s problems would be well advised to look at them.

However, there’s one free US government database that has all the NVD data, although it’s not currently set up to handle consumer traffic well: That’s CVE.org, the database formerly called “MITRE” (because it’s run entirely by employees of the MITRE Corporation). All the CVE data originates from the 300+ CVE Numbering Authorities (CNAs), recruited by CVE.org. These organizations (which are very often big software developers) prepare the CVE reports and submit them to CVE.org.

I know that some large NVD users have switched to using CVE.org as their primary data source for vulnerability information. However, they have to supplement it with data currently only found in the NVD. The need to do this will hopefully go away soon. This is because the three items that are added to the CVE reports by NIST/NVD staff members when they are forwarded by CVE.org to the NVD – CPE names, CVSS scores and CWEs – should really be created by the CNA. After all, the CNA is usually the organization that wrote the software; why should any other organization create these three items?

I’ve heard the CNAs will soon have the power to add those three items to the CVE reports themselves, which should help a lot. This means that, to learn about new vulnerabilities and the software products they are found in, a former NVD user will be able to get everything they need in CVE.org – although at least a few changes will probably be needed before that can be the case.

There are two big reasons why CVE.org would be the logical “replacement” for the NVD. The first is that CVE is a much more modern, robust database than the NVD, and has full redundancy. Parts of the NVD are very old, and there are multiple single points of failure. Were the database not old and non-redundant, it’s hard to believe the NVD would still be crippled today, more than 45 days after the problem first started. It’s also hard to believe there would still have been no announcement regarding what happened and why it’s taking so long to fix the problem – and what will be done to prevent the problem from recurring.

The second reason is that, because it is a much more modern database, CVE.org can accept CVE reports prepared using the CVE JSON 5.1 specification. That specification allows purl identifiers to be included for affected products, along with CPE names for them. This is because Tony Turner, on behalf of the OWASP SBOM Forum, submitted a pull request for this to CVE.org two years ago; it was accepted for the 5.1 spec.

The main reason why the CNAs haven’t used the 5.1 spec so far is that, for purls to be usable for product lookups, the NVD would have to be using the 5.1 spec. The NVD just recently began to support the 5.0 spec (after a struggle to get that to work in the current NVD environment), so it’s unlikely they’ll support 5.1 for probably a couple of years at least.

It’s also important to remember that there are open source software vulnerability databases, including free ones like OSV, OSS Index and GitHub Advisory Database. These all utilize purl, the identifier that is now in use in almost every vulnerability database worldwide that isn’t the NVD or derived from it. Since your success rate for finding open source projects using purl will in theory be almost 100%, you are much more likely to find a vulnerability for an open source component in one of these databases, than by looking in the NVD. CPE names are not well suited for identifying open source software, as discussed in the SBOM Forum white paper linked near the top of this post.

To sum up this section, there’s no danger at all that data from the NVD will be lost if it moves to the CVE.org infrastructure. Moreover, if you have confined your organization to just searching for vulnerabilities in the NVD, you are missing out on a wealth of other vulnerability data (a lot of it free) that isn’t in the NVD at all.

4. I don’t want the people who work for the NVD to lose their jobs.

This is a laudable sentiment, although it would be a travesty to protect about 20 jobs at the cost of greatly impeding thousands of NVD users from being able properly to perform their jobs.

However, the question is moot. NVD staff members are all NIST employees; they enjoy the job protections of all federal employees. Specifically, since NIST has lots of cybersecurity projects going on all the time, it’s safe to say none of them will be on the street soon, unless they want to be.

 

To summarize, it seems that the NVD user community faces a clear choice:

1.      Wait for the NVD to figure out what its problems are and how to fix them, since they have yet to announce anything regarding either of these topics. The only suggestion they have provided so far is that the Consortium may be able to figure all of this out and make the necessary changes to the NVD software infrastructure. Even if that is true, it won’t have any impact on the problems for at least a year, and most likely longer than that.

2.      Start visiting other vulnerability databases, paid and free, and learn about the vulnerability data you haven’t yet taken advantage of.

It seems clear that what needs to be in place in the future is a global vulnerability database. However, as I pointed out in this post last year, it seems likely that the best way to create that isn’t to gather together and “harmonize” all the data in vulnerability databases worldwide. Let’s leave the data where it is now. At the same time, using the vulnerability and software identifiers already in use in vulnerabity databases today, we should just create a “switching hub” to route user queries among the appropriate databases. This will allow each vulnerability database to continue doing what it does best, while making its data available to any user in the world.

The OWASP SBOM Forum has been discussing all the above issues for the past few weeks. We’ll continue to do so until the situation is much clearer than it is now. You’re welcome to join us at our Friday meetings at 1PM Eastern time. Please email me if you would like to start attending these meetings.

The Forum would also like to start work soon on one or more white papers (most likely more than one) on the path forward for vulnerability database users. This will include vulnerability database options that NVD users have in the near term, as well as options the entire software security community has in the longer term. We will probably start holding separate meetings to discuss and develop the above white papers.

We want to have the meetings as early as possible in the morning, consistent with attendance both by people on the West Coast and people in Europe (I’m sorry, Asian countries, but you’ll probably be literally left in the dark for these meetings. My wife is Vietnamese, and I’ve often tried to figure out a good way to conference with people in the US when I’m in Vietnam. I’ve concluded there’s no good answer).

To do this, we will need to receive financial support, since organizing and running these meetings, as well as conducting research on the many issues that will inevitably arise, will involve a serious time commitment by one or two of our leaders.

If your organization might be interested in supporting this effort, please drop me an email. Your donations will be to OWASP, but they will be directed to the SBOM Forum. OWASP is a 501(c)(3) corporation, meaning that donations (minimum $1,000) should usually be tax deductible. However, it’s always a good idea to check with your legal team about this.

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.

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

 

No comments:

Post a Comment