From the NVD to the IVD

In Dale Peterson’s weekly newsletter yesterday (which you should subscribe to, if you don’t now), he linked to my most recent post on the National Vulnerability Database (NVD) – although I think he may have wanted to link to the previous NVD post, which discussed his concern. He said he was “…disappointed when Tom Alrich wrote NIST gave lack of funding as a reason why they can’t improve the NVD; he further wrote that the NVD is “…a key part of extracting value from what would be a big investment in collecting and managing SBOMs.”

To address the second part of Dale’s sentence first, I completely agree with his implication: SBOMs will never become widely used (although just being narrowly used would be an improvement over where SBOMs are now among non-developers) by organizations whose primary business isn’t developing software, until issues with the NVD are addressed. Software developers are already producing and using SBOMs very heavily, but this is almost entirely for their own product risk management purposes. SBOMs are hardly being distributed to any non-developer organizations at all, and they’re being actively used by even fewer such organizations. Thus, fixing problems with the NVD, especially regarding CPE names, is without doubt one of the two “showstopper” problems that hold a filibuster-proof veto over SBOM distribution and use (the other problem is debilitating confusion over VEX).

However, regarding the first part of Dale’s sentence, I don’t agree that the leaders of the NIST team that runs the NVD (which the SBOM Forum met with two weeks ago) said they “can’t improve” the NVD due to “lack of funding”. They’re always trying to improve the NVD, although one can argue that some of their current efforts could achieve better results with more forethought, and especially with more dialogue with NVD users. Some of the most important changes we’re proposing for the NVD – those having to do with CPE names and the need to supplement them with purl identifiers – can be achieved in principle with very little expenditure of money, or even time. See this document for a description of our proposal regarding software naming in the NVD.

It shouldn’t be a surprise to anyone that all organizations are constrained by the funds they have available to them; I doubt any organization has every accomplished everything they wanted to accomplish, had more funds been available. NIST is no exception to that rule, although they’re especially constrained now, since they haven’t even received all the money that was allocated to them in the Omnibus spending act that passed Congress at the end of last year. In 2022, the same thing happened and the NVD wasn’t fully funded before July. Welcome to Washington, DC.

I – and probably everybody else from the SBOM Forum who was in the Zoom meeting with NIST – was fully expecting them to point out that they were constrained by available funds. That was just a polite way of saying, “If you want to propose some grand projects for us that are going to take more funds than what we’re supposed to have now, don’t even think about it, unless you have a good idea where the money will come from. If we just got each year’s funds at the beginning of the year rather than in the middle, that alone would be a cause for great rejoicing.”

When the SBOM Forum started discussing the NVD a year ago, we just focused on problems, and what specific steps need to be taken to fix those problems. However, in the last few weeks we’ve moved on to think about these facts:

1.      The NVD is already by far the most heavily used software vulnerability database in the world;

2.      The needs the NVD addresses are rapidly expanding for many reasons, not the least of which is the great expansion of SBOM use by software developers and the even greater expansion that will likely occur once the NVD’s problems regarding CPE names can be addressed; and

3.      Even though some countries are considering building their own vulnerability databases, at least partially modeled on the NVD, it makes literally zero sense for them to do this. Vulnerabilities are universal and they don’t care about country borders. It’s much better to have one excellent international vulnerability database (IVD – remember, you saw that acronym here first) than ten mediocre country-specific databases (i.e. mini-NVDs).

On the other hand, it makes all the sense in the world that different countries would join together to build a common vulnerability database that transcends what any one country could develop on its own. That’s what we need to focus on.

The problems can all be solved fairly easily. As Dave Wheeler of the Linux Foundation points out repeatedly in our meetings, the NVD doesn’t have any problems that haven’t already been solved many times in other contexts. The real question is, “What could the NVD be if it were a truly international database, focused on serving the needs of the software development and security communities worldwide?” If we answer that question, funding won’t be an issue. Governments and private organizations worldwide will stand in line to help fund a really world-class solution.

As the old Civil Rights movement song says, “Keep your eyes on the prize. Hold on.”

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.