Bruce Lowenthal, Senior Director of Product Security at
Oracle, has been regularly updating the OWASP SBOM Forum members on what’s going
on with the National Vulnerability Database (NVD); my last post on this topic
was this
one. His latest update was on Sunday. Here are the highlights (which include
additional points he made in emails with me yesterday):
·
The total number of “unenriched” CVE reports
(i.e., reports to which the NVD has not assigned a CPE name. That means a search
on a CPE name will not reveal the vulnerability, even if the product that the
CPE applies to is named in the text field of the report. Only a “manual” text
search would reveal the product) is now 18,790. These are unenriched CVE reports
incorporated into the NVD starting in February (when the NVD suddenly drastically
reduced the number of CVE reports they enriched) and ending in mid-September.
·
This number is similar to what Andrey Lukashenkov
estimated in the August post linked above, which was “over 18,000”. You might call
this good news, since the rate of increase in the backlog seems to be
somewhat diminishing. But Bruce’s monthly numbers don’t show a consistent
trend.
·
However, the NVD is consistent in one thing: Despite
the fact that they built up a backlog of 10,557 unenriched CVE reports from
February through May (yielding an enrichment rate of less than 3%), they no
longer consider that to be part of their backlog, since they aren’t even trying
to enrich any CVEs issued before June. Starting in June, they have been
enriching an average of less than 50% of CVEs every month, but they haven’t enriched
a single CVE for the February – May period since May.
·
The last announcement they made about their problems
was on May 29, when they said “a
contract for additional processing support” would allow them to return to their
pre-February processing rate “within the next few months”. It’s now almost four
months later, and they’re still very far from reaching their pre-February rate,
which was close to 100%.
·
On May 29, they also announced, “In addition, a
backlog of unprocessed CVEs has developed since February…We anticipate that
that this backlog will be cleared by the end of the fiscal year.” Of
course, they’re referring to the end of the federal fiscal year, which is 12
days from today. Somehow, I doubt they’ll clear up their entire 18,790 unenriched
CVEs by the end of the calendar year, let alone the end of the fiscal year. Bruce’s
numbers showed that the backlog continues to grow at over 1,000 per month.
Given that growth rate, I calculate that the NVD will erase their backlog…envelope,
please…never.
The NVD has also been consistent in another area: They still
have not given an honest explanation for why their processing capability fell
off a cliff on February 12. However, this is now clear: It seems almost all
their CVE processing activities were performed by contractors. Another federal
agency was providing them about $4 million per year to pay for those
contractors; they suddenly withdrew that funding in February.
I would love to learn why that other agency withdrew their
funding, especially in the middle of the fiscal year. But the bigger question
is what the fact that the NVD seems to be relying almost entirely on
contractors to enrich CVEs means for the quality of that work. Fortunately or
unfortunately, we already know the answer: the quality isn’t
good.
While CPE was the first machine-readable software identifier
to make the big time more than two decades ago, its weaknesses have become more
apparent in recent years, especially because the purl identifier has been so
successful in the open source software world. Even then, the fact that the NVD
was putting a CPE on almost all CVE reports made a gradual solution to the
problem – i.e., gradually switching to purl as the primary software identifier
in CVE reports – seem quite acceptable.
But today, we’re living with about 19,000 CVEs in the NVD
(and other vulnerability databases that are based on the NVD) that don’t have a
CPE, and this number is growing by over 1,000 a month. Moreover, almost all of
these are recent CVEs, which makes the fact that they’re invisible to searches even
more galling. It’s like your doctor stopped learning about new diseases in 2019
and hasn’t informed you of that fact. When you go to him with symptoms of
Covid, he has no idea what your problem might be.
Automated vulnerability management (the only kind that makes
sense for any organization other than a small one) is no longer possible for
any organization if they are tied to a vulnerability database that relies
exclusively on CPE. But, since by far the most widely used vulnerability
identifier is CVE, and a CVE report can now only use CPE name as a software identifier,
this means that most users of vulnerability databases are limited to using CPE[i].
Given the NVD’s huge backlog of unenriched CVEs, this also means that users of
CVE-based databases are described by another 3-letter acronym: SOL.
Fortunately, there is another software identifier that has
now almost literally taken over the open source software world: purl.
In fact, there is hardly any open source vulnerability database that isn’t
based on purl. However, purl currently has an important shortcoming: it doesn’t
support proprietary software products, just open source ones.
This means that, even when CNAs start including purl
identifiers to CVE reports, they won’t be able to do so for proprietary
software. Since the biggest CNAs are all proprietary software developers (Oracle,
Microsoft, etc.), and since most of their CVE reports address vulnerabilities
in their own products, this means that today most CVE reports don’t contain a
machine-readable software identifier (because the NVD has usually discouraged
the CNAs from creating their own CPE names).
To make a long story short (or shorter, at least), the
big inhibitor to replacing purl with CPE in the NVD and other CVE-based vulnerability
databases is the fact that there’s currently no clear way to create a usable
purl for proprietary software, even though in principle there should be no
problem with doing that. On page 12 of our white paper on software naming published
more than two years ago, the OWASP SBOM Forum described, at a very high level, one method of creating purls
for proprietary software; since then we have identified another method as well.
I have just drafted a white paper that describes the
importance of moving to purl in the next few years, as well as the two methods
by which we propose to develop purls for proprietary software. If you would like
to see that paper, please drop me an email.
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 and its Vulnerability Database Working Group. These two
groups work 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, which are passed through to the SBOM Forum. 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] Sonatype’s
OSS Index vulnerability database uses
CVEs, but links them to purl identifiers, not CPE names. Since the CVE reports
don’t include purls now, this means those links have been developed by Sonatype’s
own research, not the input of the CVE Numbering Authority (CNA). When they
create the CVE report, the CNA describes the affected product in text form, but
the CPE number for that product usually is – or was – created by the NVD. Since
there can’t be a one-to-one match between a CPE and a purl, Sonatype utilizes
an eclectic mix of methods to link CVEs with open source products identified
with purls.
Of course, this is certainly better than not being able
to link an open source product to a CVE at all, which is why Dependency Track relies primarily on OSS
Index for its vulnerability lookups. By the way, the last time I checked (last December),
Dependency Track was looking up vulnerabilities for a component in an SBOM 500
million times a month. Given the growth rate they were experiencing then, it’s
not hard to believe they’re now at 7-800 million lookups per month. If you’re
keeping score at home, that’s 23 to 27 million lookups every day.
Not that Steve Springett (leader of the OWASP CycloneDX
and Dependency Track projects) goes around shouting this from the rooftops. He’s
not that kind of guy.
No comments:
Post a Comment