Monday was September 30, the end
of the federal fiscal year. That morning, Patrick Garrity of VulnCheck decided
to look in on the National Vulnerability Database (NVD), to see whether they
had kept the promise they made on May 29. He pointed out in this blog post,
On May 29, NIST announced that it
awarded a contract to a third-party, Maryland-based Analygence, to help address
the backlog. Its announcement expressed confidence that “this additional support
will allow us to return to the processing rates prior to February 2024 within
the next few months.” It further stated that it expects the “backlog to be
cleared by the end of the fiscal year.”
What is this backlog? It’s the set
of “unenriched” CVE Records. You can learn what those are in this post of mine. Briefly, a CVE record describes a
newly-identified software vulnerability and includes a textual description of
one or more software products (or intelligent devices) in which this vulnerability
was found. Of course, it is good to have this information, but another piece of
information is essential: a machine-readable identifier for the vulnerable
software product(s), called a CPE name.
If the CPE name isn’t present in
the CVE Record, a software user who is trying to learn about newly identified
vulnerabilities in a software product they operate (or previously identified
vulnerabilities in products they recently acquired) will not learn about this
vulnerability through an automated search using the CPE name for the product.
This is because the search will only identify the vulnerability if the CPE name
is included in the CVE record.
In other words, a CVE Record with
no CPE name (an unenriched Record) is invisible to automated searches; the only
way for the user of a software product to be sure to identify vulnerabilities
applicable to their product, if the Record doesn’t have a CPE name, is by doing
a “manual” text search.
CVE Records are produced by CVE.org (part of DHS)
and forwarded to the NVD (part of NIST, which is part of the Department of
Commerce). Until February of this year, NIST almost always “enriched”
the record by adding one or more CPE names that correspond to the product(s)
described in the text of the record, meaning that in general almost all CVE
Records were enriched soon after they were added to the NVD.
However, that has been far from
the case this year. In fact, Patrick stated that the number of unenriched 2024 CVE
Records as of September 21 was 18,358. This is roughly the number that Bruce Lowenthal
of Oracle estimated two weeks ago, which I reported in my post
of September 18. The fact that Patrick’s number is lower than Bruce’s is
probably not statistically significant.
Patrick went on to post a few more
interesting observations:
1.
The 18,358 unenriched
CVE records amount to about 73% of 2024 CVEs. In other words, the NVD has only
enriched about one quarter of the CVE records it has received this year.
Normally, that number doesn’t deviate much from 100%.
2.
46.7% of the vulnerabilities
in CISA’s Known
Exploited Vulnerabilities (KEV) catalog have yet to be enriched. This is
important, because the fact that a vulnerability is on the list means it is
currently being exploited. In other words, it would be a good idea to patch that
vulnerability as soon as possible. The fact that the NVD doesn’t yet show – at least
in response to an automated search -close to one half of the vulnerabilities on
the KEV list is, to say the least, disappointing. The NVD was supposedly
prioritizing CVEs on the KEV list for enrichment. What happened to that?
3.
On the other hand, only
14% of 2024 CVEs do not now include a CVSS score. This is quite
impressive, given that 14% was the number of CVEs with CVSS scores not
very long ago. This is because, along with adding CPEs to CVE records, the NVD previously
also added CVSS scores; in other words, the CVSS enrichment rate fell almost as
much as did the CPE enrichment rate last February. What’s behind this impressive
turnaround? I believe it’s CISA’s “CNA
Enrichment Recognition List”, which I wrote about in this
post recently (as Patrick points out in his post, CISA’s separate Vulnrichment
program is also contributing to this improvement).
It's good to see that Patrick is working
his beat!
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 co-lead the OWASP SBOM Forum and its Purl Expansion Working Group. These 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, or to
receive easy instructions on how to donate online.
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.
No comments:
Post a Comment