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