March 2026

There’s widespread agreement within the vulnerability management community that the CVE Program’s near-death experience last week is a wake-up call to do something, although there isn’t agreement on what “something” is. I now see three possible courses of action. They are all valid, but they differ according to the time horizon involved:

1. Some people are focused on making sure the CVE Program, as currently constituted, can survive the many attacks that are likely to be aimed at it in the next year.  While there might be some tweaks made, the point is to keep the program running, not to make substantial changes. I support the survival of the current CVE Program, and if survival is the best that can be hoped for (although hopefully with the CVE Record Format amended to permit purl identifiers, along with CPEs), I can’t argue with that outcome.

2. Other people – notably the OWASP Board - are taking exactly the opposite approach: They point out that software vulnerabilities as currently conceived form just one portion of “the demands of a rapidly evolving global threat landscape.” They’re calling for redesigning the CVE Program as a federated model that will address new threats like weak cryptography and AI weaknesses. My idea for the Global Vulnerability Database is very like this, especially in that it calls for a federated approach. I will definitely participate in this effort, since it is what is needed in the long run. However, there’s no doubt this will require a years-long effort.

3. A third group of people, which includes me, is more focused on March 2026. That’s when the MITRE contract will need to be renewed again. We all hope the contract will be automatically renewed, but after the events last week we would be fools to assume that will happen. Instead, we need to assume the contract won’t be renewed. This means that in March 2026, we will need to have an alternative to the CVE Program specified and ready to implement.

I think there are two realistic alternatives to the current CVE Program:

       i.          A program that adheres as closely as possible to the current CVE Program, warts and all.

      ii.          A program that follows the outline of the current program but incorporates changes that have been discussed and planned beforehand. In other words, rather than just implementing a CVE program much like the one we have in place now, we should plan ahead for March 2026, so that we implement improvements that can’t be made while the current program is up and running. Doing that isn’t as satisfying as redesigning the program from the ground up, but it can at least be accomplished by next March.

Therefore, I’m suggesting that the vulnerability management community start discussing “intermediate term” questions like the following:

a.      Should the organization that identifies vulnerabilities (e.g., the CVE Program) be separate from the vulnerability database (e.g., the NVD), as is the case now? I should point out that this separation is unusual in the vulnerability database world, since most other vulnerability databases (besides the ones that are modeled on the NVD) are focused on open source software and curate their own vulnerabilities. On the other hand, none of these other databases comes close to approximating the scale of the CVE Program and the NVD.

b.      The CVE Program is there to serve end user organizations, but with 290,000 CVEs today, the only effective way to do that is through automation of the end user’s VM processes. How can the CVE Program focus on end-to-end automated vulnerability management for user organizations? Machine readable vulnerability notifications, prepared by or on behalf of suppliers today, can specify individual versions or version ranges. However, can today’s end user vulnerability management systems utilize version range notifications in an automated manner? If so, what goal will they accomplish by doing so?  

c.      Since the user organization usually has the choice of whether to apply a patch, patches can’t be represented the same as actual versions. On the other hand, vulnerability records need to be able to represent which previous patches have been applied. How can these contradictory goals both be accomplished in a machine readable fashion?

d.      Can vulnerability identifiers, such as CVEs and GitHub Security Advisories (GHSA) be “harmonized”?

e.      Can software identifiers, including CPE and purl, be harmonized?

f.       If neither vulnerability nor software identifiers can be harmonized, how can vulnerability databases be “federated”? That is, how can vulnerability databases that use different identifiers respond jointly to a single query? This is a fundamental question that needs to be answered before the Global Vulnerability Database can be designed.[i]

There are also important questions that need to be asked about intelligent devices.

g.      How can devices be identified in vulnerability databases? There are many problems with CPE identifiers for devices, besides the well-documented problem that since last February, CPE numbers have not been produced by the NVD in anywhere near the volume they should be; this means that most devices identified as vulnerable in a CVE Record created after February 2024 will be invisible to an automated search today.

h.      The SBOM Forum’s 2022 white paper on software identification in the NVD suggested (on pages 12 and 13) that two of the standards from the GS1 family, GTIN and GMN, could be utilized as device identifiers, since they are already widely used in international trade. There are other options as well, but there needs to be discussion of this question, especially since the US Federal Trade Commission (FTC) is now at least proposing to implement a “device cybersecurity labeling program” for IoT devices. It’s hard to discuss cybersecurity for IoT without being able to learn about software and firmware vulnerabilities that apply to a device.

i.       How should vulnerabilities be reported for intelligent devices? Should they be reported using the identifiers for the individual software and firmware products installed in the device or using the identifier for the device itself? The latter option makes it much easier for users to learn about vulnerabilities that affect devices they rely on, since the user doesn’t need to have an up-to-date software bill of materials (SBOM) for each device they operate. This is the option that some big device manufacturers like Cisco and Schneider Electric have chosen to follow. However, it seems the great majority of intelligent device makers, including medical device makers, don’t report vulnerabilities to the CVE Program at all, making their devices invisible to NVD users.[ii]

j.       Speaking of intelligent devices, there’s a fundamental contradiction at the heart of patching them. In most cases, a device user is not able to apply a patch for a single vulnerability or subset of vulnerabilities; instead, they need to wait for the next full device update from the manufacturer.

k.      Because of this, the device manufacturer might delay notification of a vulnerability if the next full update is not imminent, even though they have developed the patch for it. However, delaying the notification will leave users unaware that their device is affected by the vulnerability. This means they are unlikely to apply other mitigations, like removing the device from their network or isolating it on its own segment. This problem almost certainly doesn’t have a simple answer, but it at least needs to be brought into the open, so that users can be aware of it.

My point in this post is that, while the fundamentals of vulnerabilities and vulnerability databases need to be rethought in the long run, there’s also a need to consider intermediate-term questions like the ones described above. As many of these questions as possible need to be answered by March 2026, since it’s quite possible that the vulnerability management community will find itself in a real crisis then (not just a 24-hour one). It would be good to be able to implement some solid changes to the current CVE Program, even though they’re not the ones we would implement if we were given 1-3 more years to do so.

Would you like to participate in these discussions? The OWASP SBOM Forum sponsors a Vulnerability Database Working Group that meets every other Tuesday at 11AM Eastern Time (April 29 is the next meeting); this group discusses intermediate-term questions like these. And the SBOM Forum itself meets on Fridays at 1PM ET (May 2 is the next meeting). That group discusses lots of ideas, including long-term ones. Drop me an email if you would likean invitation.l

Don’t forget to donate! To produce these blog posts, I rely on support from people like you. If you appreciate my posts, please make that known by donating here. Any amount is welcome!

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. 

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 am sure this question can be answered. AI will probably play a large role in that answer.

[ii] CISA maintains a database of vulnerabilities for industrial devices and medical devices. However, since the vulnerability identifiers are not CVEs, a user of the NVD or another CVE-based database will not usually learn of those vulnerabilities, unless the manufacturer has also submitted the vulnerability to the CVE Program.