How will the NVD survive? Will it survive?

 

The discussions of weighty fiscal matters in DC over the weekend coincided with my working on specifying what exactly we (the SBOM Forum) would like to see happen to the National Vulnerability Database (NVD).

Of course, we all wish it well, but I have to admit that, given the spending compromise that emerged over the weekend and the fact that most of the burdens from that compromise will fall on the non-defense, non-entitlement sections of the budget, the outlook for the NVD isn’t brilliant (to paraphrase Casey at the bat).

At best, the NIST NVD team will limp along for the next two years in their current uncertain state. As I mentioned in a previous post, for the second year in a row, the NVD team at NIST hasn’t yet – as of May - received the full amount they were supposed to get starting in January of this year. Last year, they didn’t get it until July. Will they get their full funding at all this year, given that the whole funding picture for NIST has probably changed for the worse because of the upcoming freeze? Because of the delay in receiving their funds, six of the 25 NIST employees allocated to the NVD already have to work “temporarily” on other projects that have full funding).

Fortunately, I don’t think the NVD will go away. But it’s also certain that their travails aren’t going to end anytime soon, meaning any significant improvements in the NVD may be pushed back off the table for now.

I believe that the CPE problems described in Section A of this document can be addressed regardless of funding levels for the NVD – but that’s only because I believe CVE.org may be able to step in and take steps that the NVD itself can’t take (CVE.org runs the CNA program and takes in all of the CVE reports. These then “flow down” to the NVD. CVE.org is a mixed government/private group, funded by CISA/DHS, that oversees the work of the contractors from MITRE who operate the CVE program. See the diagram of how the NVD works at the bottom of this post). However, the other problems described in that document probably can’t be addressed without additional funding from some source.

And that’s where the global database idea comes in. This weekend’s agreement means that the NVD’s funding is likely to be precarious at best for many years. But, even if the NVD didn’t have serious problems now, we would be remiss if we weren’t at least starting to lay the foundation of a global database. There are three big drivers for this:

1.      The EU’s proposed Cyber Resilience Act, which will almost certainly be approved by the European Parliament this year or next and will start to come into effect almost immediately upon approval. The CRA will require that all software and hardware products with “digital elements” sold in the EU (no matter who sells them or where they’re made) follow a strict set of cybersecurity standards. The standards will require protecting against software vulnerabilities, not just at the time of sale but thereafter, as long as the product is supported. The potential penalties are huge.

2.      The CRA is likely to provide a big boost to SBOM production by suppliers worldwide. Even though it doesn’t directly require that SBOMs be distributed to customers, it makes clear that SBOMs are a good security practice. For example, if a product is responsible for a breach and the supplier can’t produce an SBOM that describes the product at the time of the breach, it probably won’t go well for them.

3.      Even without the CRA, suppliers are making heavy use of SBOMs now (although they’re hardly distributing them to their customers at all – mostly because the customers aren’t asking for them). Managing component vulnerabilities identified through SBOMs requires a huge amount of vulnerability database usage. As I’ve mentioned often, just the single open source software composition analysis tool Dependency-Track is now used over ten million times every day to look up vulnerabilities for components identified in SBOMs. And this is almost entirely due to use by developers; once software customers start receiving and using SBOMs for component vulnerability management purposes, their usage of vulnerability databases will ultimately dwarf usage by developers.

In other words, a tsunami of vulnerability database usage is on the way and it’s going to be worldwide, not just in the US or even North America. There will need to be a truly global vulnerability database (in fact, that’s the name we’re now working with – GVD) that is supported worldwide and run by a truly international organization. It will certainly draw on what’s best about the NVD (including the 200,000+ CVE records on which the NVD is based), but it will need to be built on a new foundation.

Sounds far-fetched? Have you ever heard of or used DNS? More specifically, do you think there are many single days when you don’t – usually without thinking about it – use DNS hundreds or thousands of times a day? If so, you’re probably wrong.

DNS was dreamed up by Paul Mockapetris in 1983, but do you know who the first domain registrar was? The NTIA – yes, the same group (part of the Dept. of Commerce) that played a big role in developing the SBOM concept. They ultimately turned the registrar job over to the Internet Assigned Numbers Authority (IANA), which continues to manage DNS today – with a $100 million annual budget. The IANA (part of ICANN) is a truly international organization, funded by governments and private organizations worldwide. The GVD will probably need to be housed by a similar organization, either an existing or a new one.

At the moment, the need is to talk with organizations and governments worldwide to learn what they would like to see in the GVD, and what they might contribute to fund it. Armed with that knowledge, we can then develop a realistic design, both for the near and longer terms. The SBOM Forum is talking with a security-focused international nonprofit now about funding this Discovery and Design effort.

How the NVD works

                   By Rube Goldberg - Originally published in Collier’s Magazine, September 26 1931

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.