One of the unfortunate byproducts
of vulnerability management compliance requirements is that they tend to reward
negative findings. That is, if you search a vulnerability database for products
that you use and find that some product searches don’t yield any vulnerabilities
at all, you might take this as evidence that the products are very secure and
you must be compliant.
However, often that’s far from the
truth. The negative finding can mean:
1.
The person who created
the identifier for the product in the vulnerability database made a mistake or
didn’t follow the specification. Because you searched using the correct
identifier, the search failed.
2.
The product you’re
searching for has been acquired by a different supplier, who enters new vulnerabilities
under their name, not that of the previous supplier (from which you acquired the
product). That search fails, too.
3.
The supplier name reported
was for example “Microsoft, Inc.”, but it is recorded in the identifier as “Microsoft
Inc.” Again, the search fails.
4.
A product has been
entered in the vulnerability database using multiple names, e.g. “OpenSSL” vs
“OpenSSL_Framework”. However, a vulnerability is seldom reported using multiple
names, since it’s unlikely that the CVE Numbering Authority (CNA) that reported
the vulnerability knew there were multiple names available. Thus, due to pure
chance, one name might have no vulnerabilities reported against it, while the
other may have a lot of vulnerabilities, even though they’re in fact the same
product. If you happen to enter the name for the version with no vulnerabilities
reported, your search will again fail.
5.
Even though the identifier
in the database is correct, you fat-fingered the identifier in the search bar, so
the search failed.
6.
The supplier of the
software product has never reported a vulnerability for it. Instead of the
negative finding being good news, it means the supplier cares very little for the
security of their products or their customers. The great majority of software vulnerabilities
are reported by the developer of the software or the manufacturer of the device.
However, it’s certain that reported CVEs (about 260,000 have been reported since
1999) are a tiny fraction of all software vulnerabilities. Lack of
vulnerability reporting is the biggest obstacle in the way of securing the software
supply chain.
In the National Vulnerability
Database (NVD), the above problems are compounded by the error message the user
receives almost every time a search is unsuccessful: “There are 0 matching
records”. Since this message also appears when a product truly doesn’t have any
vulnerabilities reported against it, in all the above scenarios you might reasonably
assume the product is vulnerability-free. In fact, human nature dictates that
most of us will make that assumption. Of course, in most cases it’s probably
not true.
What is the solution to these
problems? I don’t know of any solution to all of them, but I can point out that
the first four problems will not appear if the identifier used in the vulnerability
database is purl
(the product identifier used in almost all open source software databases) as
opposed to CPE (the identifier used by the NVD and databases that are based on
the NVD).
This is why the CVE Program (run
by cve.org) is now looking at including purl
as another identifier in what I call the “CVE ecosystem”. This includes all
vulnerability databases that utilize CVE as the vulnerability identifier (there
are many other vulnerability identifiers, mostly for open source software products.
However, CVE is by far the major vulnerability identifier worldwide).
Of course, the most widely used
vulnerability database in the CVE ecosystem is the NVD. When the CVE Program
adopts purl as an alternative identifier, will purl suddenly be usable for
searches in the NVD? No. To support purl, a vulnerability database that
currently just supports CPE will need to make several changes. Given the problems
that the NVD has been experiencing over the past 11 months, it isn’t likely
they will be able to suddenly devote resources to making them.
However, other databases will be
able to display CVEs that apply to a software product when the user enters a
purl[i]. This means that at least
some of the CVE Records published by CVE.org will be accessible to users and developers
of open source software products.
It will be at least a couple of years
before purl is fully supported in the CVE ecosystem. That might seem to be a
long time, if it weren’t for the fact that six months ago I would have told you
it’s unlikely that purl will be supported by CVE in this decade. Things are
starting to move in the right direction.
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.
[i] There
are two large vulnerability databases that display CVEs that apply to an open
source software product/version when the user enters the purl for that
product/version. However, these databases don’t include the CVE Records published
by the CVE Program, since those records currently don’t include purls. When
that changes, those two databases will be able to accept new CVE Records, thus
making those records searchable using purl.
No comments:
Post a Comment