Last August, I wrote a post called “A Global
Vulnerability Database”. In the post, I wrote about a disappointing experience
the SBOM Forum (now the OWASP SBOM Forum) had recently had with Tanya Brewer of
NIST, the leader of the NVD. We had reached out to her in early 2023 and
offered to help the NVD, especially regarding implementing the recommendations
in the white
paper we published in 2022 on how to fix the NVD’s problems with software
naming.
We first met with Tanya in April 2023. She said then that
she’d like to put together a “public/private partnership” so that we and one or
two private corporations – who had also offered to help them – would have a structured
way to do that. When she talked to us again in June, she had worked out with
NIST’s lawyers the idea for a “Consortium” which organizations could join to
help the NVD – although it seemed the main help she wanted was for companies to
provide her warm bodies, which were attached to minds that knew something about
coding.
Those bodies would need to be ensconced at the NVD for at
least six months. The first couple of months would be spent learning some obscure
programming language I’d never heard of (which says something, since I wrote my
first couple of programs on punch cards). Offhand, suggesting that young,
ambitious coders spend 6 months immersed in working with a decades-old language,
probably used nowhere but the NVD, didn’t seem to me to be a wise career
suggestion. However, we all appreciated her enthusiasm.
She described in detail her plans to announce the Consortium
in June, have it published in the Federal Register in August, and get it up and
running by the end of the year. Those plans seemed very unrealistic but again,
we appreciated her spirit.
However, that spirit seemed to dissipate quickly; in fact,
the next we heard about the Consortium was in NIST’s announcements about the
NVD in late February, when NIST pointed to the Consortium as the cavalry that
was at that minute galloping through the sagebrush on their way to rescue the
NVD from its problems. However, it seems the cavalry lost its way, because –
despite Tanya’s promise at VulnCon in late March that the Consortium would be announced
in the Federal Register imminently – nothing more has appeared on that front (I
think the cavalry got enticed by Las Vegas when they galloped through it. They
haven’t been heard from since).
By the time I wrote the post last August, I was already disappointed
that we hadn’t heard back at all from Tanya, and I began to wonder if just
maybe the NVD wasn’t quite the pillar of the cybersecurity community that
we believed it was.
This was why I started thinking more about an idea we’d
talked about a few times in the SBOM Forum: the need for a vulnerability
database that wouldn’t be subject to the vagaries of government funding, in an
era when a bill to name a post office after George Washington might prove too
controversial to get through Congress and the US has to decide every couple of
years whether it wants to pay its debts at all.
In our discussions, we had agreed:
1.
This should be designed as a global database
from the start. Governments and private sector organizations worldwide would be
welcome to contribute to it, but we didn’t want the database to be dependent on
one primary source of funding, especially a government one. Been there, done
that, got the T-shirt.
2.
The database should follow the naming conventions
we suggested in our 2022 white paper, or something close to them. Of course,
there are still a lot of details to be filled out regarding those suggestions.
3.
Of course, putting all this data in one database,
and maintaining it over time, would require a huge effort and a lot of support
(including financial support). However, given the fact that so many
organizations worldwide have been using the NVD for free for many years, and had
an overall good experience, without once being asked to contribute a dime, I
was – and remain – sure that the support will be there when we ask for it. My
guess is there’s a lot of pent-up “contributors’ demand” that needs to be satisfied.
4.
The database would need to be developed and
implemented by a separate non-profit corporation, but once it was up and
running smoothly, it could be turned over to an international organization like
IANA, which assigns IP addresses and runs DNS
(how many hundreds or thousands of times do you use IANA’s services every day,
without once thinking about who enables all of that?).
While I didn’t write about the GVD again until November of
last year, I kept thinking about it. One thing I realized was that the idea of
a “harmonized” database – with a single type of identifier for software and
devices, as well as a single identifier for vulnerabilities (many people don’t
realize there is any other vulnerability identifier besides CVE, but there are
many of them, albeit most not widely used) was not only very difficult to
implement but also completely misses the point: There are diverse identifiers
because their subject matter (in this case, software products and intelligent
devices, as well as vulnerabilities) is diverse.
A good example of this is purl vs. CPE as an identifier for
open source software (currently, purl only works with OSS, although it has
literally taken
over the OSS world). A single OSS product and version may be available in
different package managers or code repositories, sometimes with slight differences
in the underlying code. The purl for each package manager and repository will be
different from the others (since the mandatory purl “Type” field is based on
the package manager). Yet, there will be only one CPE in the NVD and it won’t
refer to the package manager, since there’s no CPE field for that.
Thus, there can never be a one-to-one “mapping” of CPEs to
purls (or vice versa), meaning harmonization of OSS identifiers in a single
database would be impossible. Similar considerations make it impossible to have
a single identifier for vulnerabilities, with all other identifiers mapped to
it.
But I also knew that harmonization of identifiers – while probably
being an absolute requirement of database technology in say the 1970s – was hardly
necessary today, since the last time I checked it was 2024. Today, a single
database can very easily have multiple identifiers for single products, without
breaking a sweat.
But that led to another idea: Why do we need a single
database at all? After all, since the different identifiers are often used in specialized
databases dedicated to particular types of vulnerabilities or software, and
since these databases are often compiled by people with specialized knowledge
of the contents, it would be a shame to try to homogenize those data types and
especially those people. Instead of the richness and diversity available today,
we would get a bland product produced by bland people, in which a lot of the
detail had been flushed away in the name of harmonization.
However, even though we do have a rich variety of
vulnerability databases available today, it’s hard for most people to
understand how they can be used together (the SBOM Forum’s Vulnerability
Database Project will be cataloging them and providing suggestions on how they
can be used together, since in the near term there will be no single database available
with the scope of the NVD; we may start discussing the GVD in a few months. If
you’re interested in joining that group – which meets bi-weekly on Tuesdays at
11AM ET – drop me an email).
That’s why there needs to be a single intelligent front end that
directs queries to the appropriate database(s). That front end will be called
the GVD, but – and please keep this a close secret between you and me – it will
in fact simply be like the Wizard of Oz: a single man standing behind the
curtain, turning knobs and pulling levers to give the impression of a single,
massively efficient database. Pretty slick, no?
So, I wrote this
post in November. I’m pleased to say that it was met with massive, universal…indifference.
Of course, that happens to a lot of my posts. I didn’t expect anything
different this time, since there was nothing on the horizon that might make
people think we needed to start thinking about a different long-term database
solution…
…Until February 12, when the NVD seems to have been
swallowed by a black hole – and three months later, we still don’t even have a
coherent explanation for the problem, let alone the beginning of a fix. Early
this week, Brian Martin posed a long, thoughtful analysis
of my November post on LinkedIn. He raised some very good questions. I promised
to answer them in a few days, but I then decided I’d like to put up a post that
explains how I and other members of the OWASP SBOM Forum came up with the idea
for the GVD.
Here’s that post. I’ll put up a new post with the answers to
Brian’s questions by early next week. Please contain your excitement until
then.
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. Also, if you would like to learn more about or join the OWASP SBOM Forum, please
email me.
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