Almost anybody who has been
involved with software vulnerabilities in any way (even hackers!) has a
love/hate relationship with the National Vulnerability
Database (NVD). On the plus side, it’s by far the largest and best-supported
vulnerability database in the world. But on the minus side, there are many problems
that make it hard to use the NVD, and in many cases make it impossible to find
vulnerability information which almost certainly is in the database somewhere
or other.
A little less than a year ago, I
convened an informal group of “SBOM industry” leaders to discuss why it is that
SBOMs are grossly underperforming, at least when it comes to distribution to
and use by organizations whose primary business isn’t software development.[i] The goal of the group was
not just to discuss those issues, but to figure out how they can be addressed,
and do what we can to set them on the road to being resolved. We call ourselves
the SBOM Forum, and we meet weekly on Zoom.
We decided that, while there are a
lot of issues that are inhibiting SBOM distribution and use, we would focus on
the show-stopper issues; I personally think there are no more than three or four
of these. We didn’t have a formal discussion of which issue we would address
first, but within two meetings we had found it: the naming
problem.
However, even we weren’t stupid
enough to try to take on the entire naming problem, which has many aspects and
is found to some degree in every software or vulnerability database in the
world. We focused right away on the Big Daddy of vulnerability databases, which
was the one we all had experience with. The NVD uses “CPE names”
to identify products, and those are the source of a lot of problems; we
described those problems in pages 4-6 of the proposal
we published on the OWASP site last September. Our proposal described how to
fix (or at least greatly remediate) the problems with CPE, although this
required involvement of a few other federal government and private sector
organizations.
That proposal was meant to address
the bulk of the naming problems in the NVD, and we’re hoping it can be completely
implemented in 2-3 years (which of course is close to light speed when you’re
dealing with the federal government). The appropriate agencies in the federal
government started considering our proposal, and we were fairly sure it was on
the road to implementation in our time frame.
After publishing our proposal, we had
discussions on other topics and were settling in on VEX as our next topic. In
my opinion, VEX and the naming problem are the two biggest show-stopper problems
preventing SBOMs from being distributed and used by non-developers.
However, recently we became aware
of a reason why implementation of our proposal might be delayed significantly
longer than three years. We had a meeting to discuss this problem. While we
received some assurances then that our immediate fears might be overblown, we
ended up having a more wide-ranging discussion of the NVD, at which other
issues came up. At the end of that hour-long meeting, we decided we wanted to
focus on the NVD itself next, and not limit ourselves to discussing just the
naming problem within the NVD.
We have representatives of some
very big software and intelligent device suppliers in the SBOM Forum (as well
as a number of smaller tool vendors and a few consulting firms. We only have a
few end user organizations and we’d like to have more), who were surprised to hear
what was said about some NVD problems that have nothing to do with naming. They
wanted to hear about all the problems the other members of our group had run
into.
Even more importantly, we started
to have a discussion about what the NVD could be if it were allowed to move out
of the narrow box it finds itself in now. For example, given that people all
over the world use the NVD, yet the entire physical infrastructure is housed in
the US, what might happen if the NVD could place infrastructure (perhaps
through content delivery networks) on other continents – while at the same time
getting support from private and public sector organizations on those other
continents?
Note that I don’t for a minute
blame any individuals, or even government agencies, for the NVD’s problems. Any
organization that’s grown very rapidly, yet has to fulfill the obligations of being
a government-controlled entity, will probably find itself in a similar box
sooner or later. In fact, there’s a great example of a similar organization
that was incubated in the NTIA, the same federal
agency that “incubated” the Software Component Transparency Initiative, also
known as “Allan’s Army”. That organization found itself in an overly box much
quicker than the NVD has, and now it’s a very effective private sector
organization, that gets some help from governments.
Has anyone heard of DNS? Let me put
that another way: Is there anyone who uses DNS fewer than perhaps 5,000 times a
day (almost always without even thinking about it, of course)? Our lives would
be very different if, instead of being able to find any web site we want through
a single DNS query, we had to first obtain from the operators of the site
(perhaps by calling them – do you remember phone calls?) their 31-hex character
IPv6 address, then enter it by hand in our browser. And woe betide you if you
got one of those characters wrong; you’d have to re-enter it until you did it
perfectly.
Without going into a lot of
detail, the NTIA saved you from that fate by picking up an idea developed by an
academic named Paul
Mockapetris and turning it into a real service. In fact, NTIA itself was
the first domain name registrar. But, as you can imagine, business grew very
rapidly, and since the NTIA (and the federal government in general) doesn’t
want to go into business doing something the private sector could probably do
better and certainly less expensively, they looked for a private sector
organization to take over this role.
The NTIA first made a false start
when they chose a network consulting firm to handle domain registrations. After
a couple years of performing well, they one day decided it would be a great
idea to email organizations that requested domain names to see if they’d like
some of their other services; that email set off a firestorm, and the NTIA
looked for a different organization to take over domain registrations. Finally,
they turned the business over to the Internet
Assigned Numbers Authority (IANA), which remains in charge of assigning
domain names to this day.[ii]
Our group is now in the process of
enumerating both problems with the NVD as it exists today and opportunities it could
have in the future, whether or not it remains a part of the US government and
whether or not it retains the NVD name. We have some ideas already, but we’re looking
for others. If you have anything you would like to contribute to this
discussion, either with a comment or by suggesting a text edit or addition, please
go here.
You can contribute either using your email address or anonymously. We would
prefer the former, but we want most to hear what you have to say, no matter how
you say it.
Once we have our list of problems and
opportunities together, we’ll make that publicly available. We’ll also start
discussing how those problems and opportunities can be addressed, both in the
short term and the long term. You’ll be welcome to participate in that as well.
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.
[i] The good news is that SBOMs have had tremendous success in being adopted by the software developer community, in no small part due to the efforts of Dr. Allan Friedman and the NTIA. Developers have come to realize that they need to take much more responsibility for assuring the security of the components they include in their products, and it’s literally impossible to do that without producing SBOMs at every point in the development process.
However, the bad news is that developers are almost never distributing SBOMs to their customers (at least not regularly. A new SBOM should be distributed with every major or minor version, since the previous one becomes almost completely invalid at that point), meaning their customers aren’t able to make use of them for their own software risk management purposes. However, the suppliers generally can’t be blamed for this situation; the fact is that the users aren’t asking for them.
[ii] Given
what a success story this is, wouldn’t you think the NTIA might brag a little
about it on their web site? I would too, but I can’t find it anywhere.
No comments:
Post a Comment