In our meeting of the OWASP SBOM Forum last Friday, we were –
of course – discussing the fact that the National Vulnerability Database (NVD) now
has a backlog
of over 17,000 “unenriched” CVE reports. Moreover, even though they are
enriching about 75 newly received CVE reports every day, they are still adding
over 100 unenriched reports to the backlog every day, because of the volume of
new reports being generated.
An unenriched CVE report is one that describes a
vulnerability and includes a textual description of the affected product, but does
not include a machine-readable CPE identifier for the product. The problem with
this is that the only way the report can be read by an automated process (e.g.,
by a software composition analysis tool or a vulnerability scanner) is if it
includes a CPE; otherwise, the automated process will not normally be able to
learn what product(s) the report applies to. It isn’t useful for a process to
be able to learn about a newly discovered CVE if at the same time it can’t
learn about the affected product.
The NVD essentially stopped enriching CVE reports on
February 12. In May, it started enriching about 75 a day; I’ve heard that
number has slightly increased. But the facts that there was almost no
enrichment for more than three months and that the backlog is still increasing
by about 100 per day, mean that an NVD search for vulnerabilities applicable to
a particular product is unlikely to discover any of the more than 17,000
vulnerabilities identified since early February.
Frankly, if you are trying to learn about all the vulnerabilities
that may be found in a software product you utilize, not knowing about the
great majority of vulnerabilities identified since early February makes it
almost a complete waste of time even to conduct an NVD search. In fact, if you
interpret the lack of results to be an indication that your product has no vulnerabilities
– when in fact it may be loaded with them – then even doing the search probably
causes more harm than good.
In Friday’s meeting, Yotam Perkal of Rezilion asked a
question about what vendors of security scanners are doing about this problem,
since a lot of them use the NVD to find vulnerabilities in software being scanned
– or at least they used to. He wondered if they’re still using the NVD, and if
so, why they are doing that. Are they getting something useful out of it, or
are they simply going through the motions, so that their customers continue to
believe they’re gathering useful information in their scans – when in fact they’re
probably living in a fool’s paradise?[i]
Nobody in the meeting had the answer to this question,
including me.
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] I
honestly don’t remember how Yotam phrased his question, but this was the gist
of it.
No comments:
Post a Comment