As my post
on Monday lamented, we’re suffering from a severe shortage of CPE names. CPE
stands for Common Platform
Enumeration. Any lookup to the National Vulnerability Database (or to any other
database based on the NVD) needs to include a CPE name.
The reason we have a shortage – actually, an almost complete
drought – is because, until February 12 of this year, the NVD staff itself (NVD
is a part of NIST) was the only “authoritative” source for CPE names – and they
ceased being that on that day.
As I also explained in the post, the source of the data in
the NVD is CVE reports submitted to the CVE.org database (which used to be
called just “MITRE”, since MITRE Corporation contractors originally developed
and still operate the database) by CVE Numbering Authorities (CNAs). In most cases,
the CNA is the developer of the software in which a new vulnerability was
discovered.
In the CVE report, the CNA always describes the software
product (or sometimes multiple products) in a text field (e.g. “Joe’s Word
Processor version 2.3”), but they aren’t expected to (or even allowed to, in
many or most cases) create the CPE name for the product/version; until February
12, an NVD/NIST staff member or contractor almost always did that.
After February 12, the NVD essentially stopped adding CPE names to CVE reports; in June, they resumed adding them, although they’re now adding a CPE to just about 25% of new reports. While this is some progress, it’s important to keep in mind there’s now a backlog of over 16,000 CVE reports that don’t yet have CPE names. That backlog is growing by over 100 CVEs a day, even though the rate of growth of the backlog has been reduced (I want to thank Andrey Lukashenkov of Vulners for discussing these issues with me constantly. Today, he pointed me to this report on the NVD, which is updated every six hours. That’s a good one to follow).
This means that, if a software user searches for a particular
version of a software product in the NVD today, there is only a tiny chance (and
it diminishes as the backlog keeps growing) that the user will learn of a CVE
that has been reported for that product/version since early February. Of
course, a user can avoid this problem if they read the text of every CVE report
released since early February (around 200 CVE reports are added daily) and
decide whether one of the many software product/versions they use is referenced
in any of that text. However, that won’t leave much time for them to do their
day job.
Since most users are concerned about recently reported
vulnerabilities for the software they use, this is of course a huge problem. It
means that true vulnerability management (which needs to be automated) is
currently impossible, at least, if you continue to rely on just the NVD for
your vulnerability identification needs. Even if the NVD were to double their current
rate of creating CPEs tomorrow, it would still be more than a year before they
dig themselves out of the hole they’re in.
Which brings me to purl, which I discussed in my last post
and is discussed at length in this
document. Purl is now supported by the CVE specification (v5.1), so the CNAs could
in theory start adding them to their reports tomorrow. Would it be any more
efficient if they were to do that, rather than have the NVD continue their
Sisyphean effort to decrease their naming backlog by tripling or quadrupling
their current rate of production?
In fact, it would be 100% more efficient. This is because a
purl is a completely deterministic identifier. As long as you know a) the
package manager from which you downloaded an open source project, b) the exact
name of that project in the package manager, and c) the version string for the project
in the package manager, you can create a purl that should always be an
exact match for the purl that the supplier/CNA used when they created the CVE
report[i].
Of course, this is very different from CPE, in which a product supplied by “Microsoft”
has a different CPE name than one supplied by “Microsoft, Inc.”, or one supplied
by “Microsoft Inc”, “Microsoft Corporation”, “Microsoft Europe”, etc.
Of course, if you’re gifted with clairvoyance and you know
exactly which vendor name the NIST/NVD staff member used when they created the
CPE name you’re looking for, you’ll find it easily. But for the rest of us…not
so much.
So which is better – hope and pray that the NVD will finally
get their act together and catch up on their CPE backlog in a year or two, or
start moving now toward making purl the primary identifier for the NVD and its
clones, with full understanding that it will be years before we’ll be able to
say goodbye to CPE forever? As I’ve said before, I don’t know of a single
vulnerability database anywhere in the world that is not based on purl, other than the NVD and
its near-clones. There must be a reason for that.
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 lead the OWASP SBOM Forum, which works to understand and address issues like what’s
discussed in this post; please email me to learn more about what we do or to
join us. You can also support our work through easy directed donations to OWASP,
a 501(c)(3) nonprofit. Please email me to discuss that.
My book "Introduction to SBOM and VEX" is available in paperback and Kindle versions! For background on the book and the link to order it, see this post.
[i] Purl
supports other fields, of course, but the three just listed are the only ones
required.
No comments:
Post a Comment