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:
- 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%.
- 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?
- 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.
