How can we get out of the CVE rat race?

Chris Hughes’ June 24 post pointed out what a lot of people involved in vulnerability management already knew: The number of new CVEs is rapidly growing, along with the cost of tracking and patching those CVEs. Those increased costs include both money and staff time, but also the huge costs due to having to divert management attention from activities that will grow the business to tedious vulnerability management tasks that don’t grow anything except aggravation.

The numbers behind Chris’s argument all came from a paper that was recently put out by Chainguard, a company that has quickly become one of the two or three thought leaders in the field of software security. I paid close attention to the post, primarily because I think highly of Chainguard. I consider anything they feel strongly about to be worthy of an investment of my time – and they certainly feel this is an important topic. I read both Chris’s summary of Chainguard’s paper and the paper itself.

The primary takeaway from both Chris’ post and the Chainguard paper was that organizations that decide to undertake vulnerability management on their own are making a big mistake. Instead, those organizations should seriously consider outsourcing vulnerability management to a services vendor that specializes in vulnerability management. They should do this because such a vendor can manage their vulnerabilities much more efficiently than any single software end user or software developer organization. Of course, the only vendor mentioned in the paper is Chainguard itself.

I have no objection to a company putting out a paper that describes a problem that is likely to affect many of the people that read the paper, and then using that description as a lead-in to a sales pitch for their services. In fact, I doubt there are many technology companies that haven’t done exactly this. However, I think Chris could have mentioned that there are other ways to beat the vulnerability management rat race, other than just suggesting that readers outsource the whole problem to Chainguard or any other services vendor.

I say this because I realized almost three years ago that vulnerability management can never really be successful unless it can be fully automated. At the same time, I realized - when the SBOM Forum (now the OWASP SBOM Forum) published a white paper titled “A Proposal to Operationalize Component Identification for Vulnerability Management” - that various problems, like those described in pages 4-6 of the paper, have made a fully automated (or “operationalized”) vulnerability management process all but impossible today. Until those problems are addressed, vulnerability management will always be a slow, “manual” process – and outsourcing it may well be the only good solution to the problem.

The problems pointed out in the paper were all related to the fact that the only software identifier utilized in the National Vulnerability Database (NVD), “Common Platform Enumeration” or CPE, is inefficient in many ways. In the paper, we recommended that both the CVE Program (which is run by the MITRE Corporation, overseen by the Department of Homeland Security) and the NVD (which is run by NIST, part of the Commerce Department) start moving toward implementing use of the purl (product URL) identifier, along with CPE.

I’m pleased to report that the CVE Program is now laying the groundwork for implementing purl along with CPE, although the process may not be finished until the end of 2025 or even later than that. However, I’m not pleased to report something that I’ve written about a lot: starting in February 2024, the NVD greatly curtailed their performance of a vital task that they have performed for more than a decade. In fact, the NVD has insisted that only they can perform this task, namely identifying vulnerable products in CVE records by creating new CPE names for them.

Since CVE records usually just include a textual description of the product(s) affected by the vulnerability, if the record does not also contain a machine-readable CPE name to identify the product, this means that an automated search of the NVD – e.g., using the NVD’s search bar – will not identify the product(s) affected by a CVE. The user (or a service provider working for them) may need to conduct “manual” text searches to learn if a product they use is affected by any recently identified CVEs. Of course, given that over 50,000 new CVEs are being identified each year and that number is itself growing rapidly, any non-automated vulnerability management process will be unsustainable, even if it’s outsourced.

How bad is this problem? According to Andrey Lukashenkov of Vulners and Bruce Lowenthal of Oracle, in 2024 fewer than half of CVE records had CPEs assigned, while in 2025 those numbers have gotten even worse. In fact, Bruce says that since last November, the NVD has completely stopped assigning CPEs to newly identified CVE records within a few days, as they almost always did in the past. Instead, they are now assigning CPEs exclusively to records that are more than a month old.

Bruce points out that this is an almost totally useless exercise, since software suppliers are much more likely to have patched older vulnerabilities; if the software supplier releases new patches within a few weeks (which the best ones do, whenever possible) and the user applies those patches quickly, most CVE records that are more than a month old are likely to be irrelevant. In other words, the NVD now seems to be waiting until attaching a CPE to a CVE record won’t be very helpful at all, rather than making the extra effort required to create the new CPE shortly after the CVE record was introduced, as they almost always did before February 2024.

Bruce also points out that in June 2025, CVE.org (where CVE records originate) has included the vendor name in about 94% of CVE records, whereas the NVD has only included vendors in about 27% of those records; since the beginning of 2025, the NVD’s record has been similar in every month. It’s no wonder that NIST recently announced an audit of the NVD; perhaps they can figure out what is going on, since I certainly can’t (and don’t tell me the NVD’s problems are due to a lack of funds. They announced last year that they finally had enough funds, but the problems have literally gotten worse since then, not better).

The bottom line is that, through almost all of 2024 and so far in 2025, any automated search of the NVD for vulnerabilities that apply to a software product has likely yielded fewer than half of the vulnerabilities that have been recently identified in the product. This means that users of those products may never know all the vulnerabilities to which their product is exposed, until it is too late. Of course, this is not a sustainable situation.

Introducing purl identifiers into CVE records (which will need to be done by the CVE Numbering Authorities – CNAs – that create the records) will help address this situation for open source software (as described in the 2022 SBOM Forum white paper linked earlier). However, since currently purl doesn’t address software not delivered through package managers (which includes almost all commercial software), a new procedure (or purl “type”) will need to be developed to identify commercial software products.

The OWASP SBOM Forum would like to start working on this problem soon, in conjunction with commercial software developers, as well as any other concerned parties. If your organization would consider donating to OWASP to support this effort (OWASP is a 501(c)(3) nonprofit organization), please email me.

Since CPE is now the only identifier for commercial software products, and since most newer CVE records do not contain any CPE at all, this means vulnerability management for commercial software has turned into an oxymoron – it is literally becoming impossible. At a minimum, a fully implemented solution to this problem is two years away, and perhaps longer than that. However, the clock won’t even start running on a solution until we start developing one; it is that simple.

Therefore, while I think all organizations that are concerned about vulnerabilities in the software they utilize or develop should consider outsourcing their vulnerability management work to a company like Chainguard as a short term solution, in no way should this be considered a final solution to the CVE rat race. The final solution is to replace the NVD with a truly robust Global Vulnerability Database that will support multiple types of software identifiers (especially CPE and purl), as well as multiple vulnerability identifiers (including CVE, OSV, GitHub Security Advisories, etc.).

In other words, vulnerability management needs to become a rigorous, fully automated process. It shouldn’t require an expert third party to fill in the automation gaps. However, since there is always more that can be done, even when today’s vulnerability management is fully automated, there will still be a need for third parties like Chainguard to push the boundaries beyond what is possible through automation today. I hope they continue to do that.

My blog is more popular than ever, but I need more than popularity to keep it going. I’ve often been told that I should either accept advertising or charge a subscription fee or both. However, neither of those options appeals to me. It would be great if everyone who appreciates my posts could donate a $20-$25 “subscription fee” once a year (of course, I welcome larger amounts as well!). Will you do that today?

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.