Stay of Execution

Today, CISA – which has been the exclusive funder of the MITRE contract to run the CVE Program – announced that it will renew the contract after all. Thus, it seems we can count on the CVE Program being in place for another year.

However, I don’t need to tell you this is no way to run a railroad. Given the NVD’s problems that started last February and seem to be only getting worse as time goes by - and now given the almost-loss of the CVE Program - it is clear that government-run programs no longer make sense, even though they may have been required in the early days of vulnerability management.

As I mentioned in my post yesterday, the OWASP SBOM Forum, a group that I lead that has been discussing vulnerability database and identification issues since the NVD’s semi-collapse in February 2024, will discuss the way forward on this issue at our regular bi-weekly meeting on Friday at 1PM ET. If you would like to join us, please drop me an email at the address below. 

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. If you would like to donate to the work of the OWASP SBOM Forum, which I lead, you can give to OWASP and have your donation (if it is over $1,000) “restricted” to the Forum. Please drop me an email if you would like to do that. OWASP is a 501(c)(3) nonprofit organization.

 

CVE circles the drain

When I wrote this post barely more than two weeks ago, it seemed to be like sounds of a faraway battle that might eventually start spilling into your region. You need to pay attention to those sounds, but you’ll get a lot more warnings before the battle starts to impact you directly. In other words, there’s no need to take your family and flee your home now. The army will protect you from the invaders; after all, look at that huge fort they’ve been building for years – it looks like it could withstand a two-year siege!

However, it seems I was wrong. Not only has the battle reached our region, but the fort was overwhelmed before it could even mount a defense – or before the defenders even knew they were in danger. In fact, it’s too late to even think about fleeing. We just have to stand silently as the victorious attackers parade through our streets and stare scornfully at their vanquished foes.

Perhaps I’m letting my metaphors carry me away a little, but this is without doubt a turning point in the vulnerability management timeline. After all, the first 300 or so CVEs were reported in 1999; last year, the total reached around 275,000. Moreover, the rate at which new CVEs are being identified is growing by leaps and bounds every year. As VulnCon showed two weeks ago, the cybersecurity community is increasingly coming to realize that software vulnerabilities are at the root of almost all the serious cybersecurity threats – e.g., ransomware – that we face. Vulnerabilities will never be eliminated, but they can certainly be managed.

Or so we hope.

Are we lost? After all, MITRE researchers came up with the idea for CVE in 1999 and MITRE has run the program to identify and document new CVEs since then – in fact, the CVE Program and the database it ran used to be called MITRE. Today, both the program and the database are called CVE.org. An independent board, consisting of public and private sector representatives, runs the CVE program. Funding for CVE.org now comes entirely from CISA (or at least it did).

It's hard to think that the CVE Program might stop dead in its tracks, yet when a contract is cancelled, that’s usually what happens. But don’t worry, we’ve been given plenty of notice. The contract expires tomorrow, April 16. We have almost 24 hours to continue to enjoy the fact that MITRE still breathes the same air we do!

But what comes on Thursday? I assume no more new CVE Records will be produced, although the existing CVE Records won’t go away. You’ll still be able to learn about many previously identified CVEs (although the serious problem I discussed in this post remains. In fact, the remedy I prescribed, implementing purl as an alternative identifier in the CVE Program, is even more important now).

Also keep in mind that there are other vulnerability types besides CVE, such as GitHub Security Advisories (GHSA) and OSV; they shouldn’t be affected by this at all. On the other hand, the 275,000 vulnerabilities in CVE.org dwarfs both of these databases, as well as the other open source security advisory databases that are mostly specific to particular ecosystems like Python. There’s no disguising the fact that the software vulnerability management universe is going to become very tightly constricted two days from today.

Fortunately, there has been ample warning that the current US government-centric system, including the National Vulnerability Database (NVD) and CVE.org, isn’t sustainable. After all, 14 months ago the NVD fell seriously behind in their self-assigned responsibility to produce CPE names and add them to CVE Records (which are, of course, produced by CVE.org. CVE is part of DHS, while the NVD is part of NIST, which is part of the Department of Commerce. I recommend you reread the beginning of this post, in which I described the two organizations). Not only has the NVD not made up the ground it lost, but it continues to lose more ground almost every day.

More than a year ago, I started talking about a Global Vulnerability Database; I have refined the idea, and I summarized it in this post 11 days ago. As you can see, the GVD won’t be a single database. Instead, it will be a federation of existing vulnerability databases (probably including the NVD and CVE.org).

I’m going to stop now; perhaps I’ll write one or two more posts on this topic this week. However, I’ve already made the decision that this Friday’s meeting of the OWASP SBOM Forum (held every other week at 1PM EDT) will be devoted entirely to this topic. In fact, we’ll probably keep doing that for a while – and we might form a separate project just to start discussing – and eventually implementing – the Global Vulnerability Database.

If you aren’t currently a member of the SBOM Forum and would like to join us this Friday and perhaps afterwards, please drop me an email.

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. If you would like to donate to the work of the OWASP SBOM Forum, which I lead, you can give to OWASP and have your donation (if it is over $1,000) “restricted” to the Forum. Please drop me an email if you would like to do that. OWASP is a 501(c)(3) nonprofit organization.

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.

 

Databases, all the way down

 

I have been attending VulnCon 2025 remotely this week, although not all the sessions. Even though the first conference was last year, VulnCon has clearly found its niche as the premier gathering place for people interested in or involved with vulnerability management. The conference is well designed and well executed.

The sessions I’ve been attending are those that have to do with software naming in what I call the “CVE ecosystem”, but which most people think of as the National Vulnerability Database (NVD). If you have been reading my recent posts, you know that:

1.      Learning about a software vulnerability isn’t very helpful if you don’t know what products are affected by it; ideally, you want to be able to search on a product name in a vulnerability database and immediately be shown all the vulnerabilities that have recently been identified in that product.  Moreover, since CVE is by far the most widely cited vulnerability type and there are now over 280,000 CVEs in the official list, affected products need to be referred to using a machine-readable software identifier. The only identifier currently supported by CVE.org (the organization funded by DHS that creates and manages CVE Records) is CPE, which stands for Common Platform Enumeration.

2.      When a CVE Numbering Authority (CNA), working for CVE.org, produces a CVE Record to report a new software vulnerability, they do not usually include a CPE name(s) to refer to affected products listed in the text of the record. The reason for this is that the NVD[i] has always wanted to be in control of CPE creation. This didn’t previously cause a big problem, since until last year, the NVD almost always created a CPE for every affected product described in the text of a CVE Record; they did this within a few days of receiving the record from CVE.org.

3.      However, starting on February 12, 2024, the NVD drastically slowed their production of CPE names, for a reason that has never been clearly explained. This has produced an ever-growing backlog of CVE Records without a CPE name. Despite several promises that they would fix the problem by a certain date, the backlog has continued to grow. Today, the backlog stands at well over 40,000 CVE Records (although a well-known vulnerability researcher estimated in the VulnCon chat that the backlog is now 52,000 records). Of course, this is far more than 50% of the total new CVEs identified since February 2024. The NVD no longer even talks about eliminating the backlog for good. My guess is they would be happy just to stop it from growing, but even that doesn’t seem likely now.

4.      Why is it bad that so many CVE Records don’t contain CPE names? It’s bad because a CVE Record without a CPE name is invisible to an automated search of the NVD. If a user of Product ABC wants to learn what vulnerabilities (CVEs) are currently present in that product, they might enter “Product ABC” in the search bar of the NVD. The user should see every CPE name that contains that text string. The user can determine which of those CPEs matches the product they use; then they can search for CVEs that apply to that CPE.

5.      However, if there are no CPE names that contain the text string, the user will receive the message, “There are 0 matching records.” The user will receive this message even if there is a CVE Record that states in its text that Product ABC is affected by the vulnerability, as long as that record doesn’t include Product ABC’s CPE name. The lack of the CPE name in the record means that searching on a CPE name will not inform the user that their product is affected by the vulnerability described in that record.

6.     But there’s a worse problem than not learning about vulnerabilities that affect the product being searched for: The above message is the same one that the user will receive if the product in fact has no identified vulnerabilities. Human nature alone dictates that most users will interpret the message this way. That is, most people will believe the product they use has no vulnerabilities, when in fact it may have a lot of them.

In my opinion, everyone in the CVE ecosystem needs to assume that CPE will never be a reliable identifier, even though nobody is saying that CPE should go away. What’s Plan B? Plan B is purl, which has come from literally nowhere eight years ago to being one of the two or three most widely used software identifiers in the world. However, purl cannot currently be used in CVE Records, so people in the CVE ecosystem currently cannot benefit from using it.

This is why I’m pleased to announce that purl will soon (let’s say in 6-9 months) be available in the CVE ecosystem. I’ve been advocating for purl for more than two years; interest in it has clearly been growing, but the day when it would become an officially accepted part of the CVE ecosystem has always seemed far away. Now, I can say with confidence that CNAs will be able to identify vulnerable products in CVE Records – and end users will be able to search for them – using purl within a year, and perhaps less than that.

Purl was discussed in at least four different sessions at VulnCon, but perhaps the most interesting was a two-hour workshop led by Chris Coffin of MITRE, leader of the CVE Quality Working Group, and Pete Allor, Senior Director of Product Security at Red Hat (both of them are members of the CVE.org Board, which runs the CNA Program within DHS). When the idea for the workshop first came up early in the year – it was primarily the brainchild of Christopher Robinson, aka “CRob”, of the Linux Foundation - the point of the workshop was to have a kind of “face-off” between purl and CPE.

At that time, the question was whether there was enough support for purl in the CVE community for the CVE Board to seriously consider moving forward with it as a second possible software identifier along with CPE. The point of the workshop was to get a “sense of the room” on this subject.

However, I was surprised (and others were, too) by the fact that in the past one or two months, the CVE Program has decided to at least start laying the groundwork for incorporating purl in the CVE Record Format. How did this change come about? While I have no specific knowledge of the reason, I attribute it in large part to the fact that in March it became clear that the NVD was not only not making progress on eliminating their backlog of CVE Records without CPE names, but they were in fact allowing it to grow at a much more rapid pace. Indeed, at the end of March, I was told that the backlog had grown from 55% of CVE Records issued since February 12, 2024 – its size at the end of 2024 – to over 70%.

In other words, searching the NVD for new vulnerabilities applicable to a software product has increasingly become an exercise in futility: You will most likely just get a message saying, “There are 0 matching records.” If you want a lift to your day, you can believe that means your product has zero vulnerabilities and you have nothing to worry about. Or if you want to be realistic, you can say this more likely means that any CVE Record that mentions the product you are searching for in its text does not include a CPE name for the product. If you want to verify this for yourself, you can always read the text of each of the 40,000 new CVE Records added to the NVD since February 12, 2024.

The CVE Program intends to change the CVE Record Format (the format used by CNAs to create CVE Records) to enable CNAs to use purl to identify a vulnerable software product, not just CPE. You might ask why that is such a big deal. After all, if the NVD is struggling to create CPE identifiers, why won’t they also struggle to create purl identifiers?

The answer is that purl identifiers don’t need to be “created”. Today, purl is mainly used to identify open source software distributed in package managers and similar repositories (of course, this includes a huge percentage of open source software products, especially of software components found in SBOMs). A typical purl is: “pkg:pypi/django@1.11.1”. The values of the fields in this purl are:

“pkg” – This field does not currently have a use, but it will in the future. Currently, all purls start with these three letters.

“pypi” – This is called the purl “type”. The package manager is designated in the type. In this case, the package manager (or more correctly, the package index) is PyPI.

 “django” – This is the product name in that package manager.

“1.11.1” – This is the version number (or “version string”) in that package manager.

If you are a CNA creating a new CVE Record that reports a vulnerability found in django v1.11.1 as it exists in PyPI, you can easily create the purl using the values for those four fields. If you’re not sure about one of the fields (e.g., you’re not sure about the spelling of django), you can verify it by checking in PyPI. Similarly, if you’re a user of django and want to learn about current vulnerabilities found in that product/version, you can look at the product itself, or else verify the information in PyPI.

The most important feature of this process is that the purl for django 1.11.1 as found in PyPI will always be globally unique. There are some open source products, like OpenSSL, that exist in multiple package managers, so the name and version string might be the same for all those instances. However, the package manager will be different in each instance. This means every purl is guaranteed to be globally unique.

By contrast, CPE names include at least two fields that are inherently ambiguous: product name and vendor name. Everyone knows that products are renamed regularly, due to M&A as well as various marketing and rebranding campaigns. But even the company name is hardly unambiguous. A consultant who worked at Microsoft once asked people there what company they worked for; she received over 20 different answers. This is compounded by the fact that software identifiers are based on a single spelling of a name, so “Microsoft, Inc” is different from “Microsoft”, which is different from “Microsoft, Inc.” with a period, etc.

The NVD mostly leaves it up to a staff member – usually a contractor – to decide what values to include in the product name and vendor name fields of a CPE name they are creating. It is likely that the only direction they give the contractor is to adhere as closely as possible to existing values in the “CPE Dictionary” (which isn’t a dictionary at all, but simply a list of every CPE ever created). Of course, the product and vendor names vary greatly in the “dictionary”, even when they probably refer to the “same” product or vendor. So, the CPE dictionary is a very week reed to lean on.

In discussions about this problem (which is the infamous software “naming problem”, unless you didn’t realize that), someone always asks, “Why don’t we just build a database of all software products and/or all software vendors? That database can have a canonical name for each product or vendor; every staff member creating a new CPE name will need to adhere as closely as possible to similar names that are located near it in the database.

That idea sounds attractive until you start thinking about it. Then you quickly realize:

1.      Creating, and even more so maintaining, a database like that would be fantastically expensive – many times the cost of maintaining the NVD itself. Remember, the database will include not just big- or medium-sized software companies, but one-person shops that ship a single product. These will have to be tracked all the time for name changes, acquisitions, etc.[ii]

2.      As my friend the consultant found out, there is no agreement on either product or vendor naming among employees of a large software company. Who will oversee decisions regarding canonical names? Since I’m sure there’s no employee at Microsoft that even knows every product they make (let alone can track all the changes in product names), it’s not likely one person, or even one department, can make that decision. The decision will have to be delegated. How will that be done, and what criteria will be provided for the people that make these decisions? Just developing training for these people – which will have to be constantly repeated, of course – will be a monumental task.

3.      I will point out one area of agreement that I’ve found in these discussions: The person who advocates for an approach like this will usually end up saying their department should oversee software naming, because they are the only department with the right perspective to make these decisions. This is expected behavior, since there’s probably no objective way to decide who should oversee software naming.

To summarize the above, trying to definitively fix CPE name creation will usually lead to requiring at least two separate databases: for software and vendor names, respectively. I don’t know of any other way that it would be possible to enforce a policy like, ‘Any software developer whose name begins with the word “Microsoft” will be called “Microsoft Corporation” (and not “Microsoft Corp.”, “Microsoft, Inc.”, etc.).’

How does purl handle the naming problem? The name of an open source product in a package manager is controlled by the operator of the package manager; whatever name they decide on is the correct one for that package manager, although another package manager may decide to give the “same” product a different name. Moreover, it’s likely those two databases will themselves require other databases. After all, if a company like Microsoft is going to designate certain people to oversee naming for certain types of software, there will need to be a database that lists each of those people, as well as the types of products over which they have authority. And that database might itself require another database, etc.

How does purl decide the “correct” name for a software product found in a package manager? It follows a simple rule: the name of the product in the package manager is presumably under the control of the operator of the package manager. That person or organization can be counted on to maintain a “controlled namespace”, in which no product name/version string combination duplicates the name/version of another product in the same package manager.

That way, the name of a product distributed through PyPI or Maven Central will always be the same for anyone who wants to look at the package manager (or even read the “About…” section on the main page of a software product they use); no centralized database lookup is required. Two different people (say, the CNA that creates a CVE Record that includes a purl for Product ABC version 1.2 and the user who wants to search for vulnerabilities in that product/version) should always, barring a mistake, create the same purl.

Problem solved.

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] The National Vulnerability Database is part of NIST, which is part of the Department of Commerce. The CVE.org organization, which used to be called MITRE and is still staffed by contractors from the MITRE Corporation, is funded by the Department of Homeland Security (DHS).

[ii] Steve Springett is advocating an idea called “common lifecycle enumeration”. This can be thought of as an online ledger of changes in names and versions of a software product.

It’s time to start discussing the Global Vulnerability Database

For a year and a half, I’ve been talking about what I call the Global Vulnerability Database (GVD) – which isn’t a single database at all, but rather a federation of databases behind a single intelligent front end. At first, I just brought it up as one of those things that will take many years to come to fruition, but which is nice to think about, anyway.

That changed in February 2024, when the National Vulnerability Database (NVD) greatly slowed down performance of their most important function: adding machine-readable software identifiers called CPE names to new CVE records. Like a lot of people, I initially believed the NVD’s assertions that they were getting back on track and would soon resolve their backlog of over 30,000 CVE records that were “unenriched” – i.e., that did not include a CPE name(s) for the vulnerable product(s). This deficiency renders those records invisible to automated searches (such as from the NVD’s command line).

However, those assertions have all fallen by the wayside. On March 19, the NVD announced, “…we are working to increase efficiency by improving our internal processes, and we are exploring the use of machine learning to automate certain processing tasks.” In other words, they’re no longer even pretending they’ll eliminate their backlog, or even stop its growth, anytime soon.

Meanwhile, the percentage of CVE records the NVD is enriching[i] in a timely fashion has probably fallen to around 25% from 45%, where it was at the end of 2024. Moreover, this week I started to hear complaints about “503” (“service unavailable”) errors when people tried to reach the NVD (I experienced six of those in one day, vs. only one success). It’s no exaggeration to say that the NVD may be falling apart in real time.

There are two problems here, with separate causes. The problem with the lack of CPE names is in some way due to cuts in funding by another agency. NIST (the NVD’s parent organization) checked between the couch cushions and found them some extra cash last year, yet if anything the problem has gotten worse since they did that. The solution to the CPE problem (although it will take a couple of years before it’s fully in place) is to make it possible for CVE records to include purl identifiers, not just CPEs. That solution doesn’t depend on the NVD, but rather on CVE.org. I trust that organization much more than I do the NVD, although I’m worried about what might happen to them as well, given the current political climate.

However, the 503 errors aren’t primarily due to funding. They’re due to the NVD having a decrepit infrastructure with at least some non-redundant systems, as well as programs written in an old language that even I – old as I am – had never heard of. The only good solution to this problem is to bring up a huge dumpster to the building and gently deposit all their current servers, etc. in said dumpster. The NVD doesn’t have to worry about backing up their data, since the entire NVD can be downloaded in about ten minutes (I’m not kidding); thousands of complete backups of the NVD are made every day.

The only solution to the NVD’s problems is to replace it. But simply modernizing the hardware and software isn’t enough. Instead, we (meaning the worldwide software security industry) need to get together to decide what objectives we need to achieve in replacing the NVD. Here are my ideas on that topic:

1.      Access to the GVD needs to be free, at least for casual users. Users that regularly download large amounts of data using an API might need to be charged, although doing that could possibly cause more problems than it would solve.

2.      The GVD must be truly global and not under the control of any one government. The budgets and priorities of government agencies often fluctuate due to political decisions, with the needs of their users - their real “customers” – taking a distant second place.

3.      The GVD should be run by a global nonprofit set up something like the Internet Assigned Numbers Authority. IANA runs DNS and assigns IP addresses worldwide. It performs these tasks smoothly and efficiently. The fact that most of us use DNS hundreds (or even thousands) of times per day without even thinking about it shows this model can work well.

4.      Support for the GVD should come from both governments and private for-profit and nonprofit organizations. Governments that want to participate (and are not considered to pose a security threat to the database or its users) might pay an assessment based on GDP, population, etc.

5.      The GVD should be as comprehensive as possible. That is, it should include all major types of vulnerabilities (CVE, OSV, GHSA, etc.), as well as all major software identifiers (mainly CPE and purl). Achieving this goal will require creation of a federation of individual databases that already exist.

6.      This federation will be enabled by an “intelligent front end”. This will analyze all requests and interpret them for one or more databases. For example, a request for vulnerabilities that affect an open source product designated with a purl identifier could be routed to open source databases that support purl, like OSV, OSS Index, GitHub Security Advisories, etc. The responses might refer to different types of vulnerabilities (e.g., CVE, OSV, and ICSA), but they would all be based on purl.

7.      The individual databases will continue to be accessible directly – i.e., not going through the intelligent front end.

8.      There will need to be some mechanism by which vulnerability databases that are currently “for charge” will be able to charge for their services, perhaps on a per-transaction basis. Of course, the user will need to be warned when their search is about to be routed to a for-charge database.

9.      Responses will usually be routed back to the user without change, since it is usually impossible to “harmonize” different types of vulnerabilities. The exception to this rule is cases in which the person reporting the vulnerability (often a CVE Numbering Authority) has assigned it two identifiers, e.g. a CVE and an ICSA.

10.   The NVD does not need to go away, since it is the primary “custodian” of CVE records that include CPE identifiers for vulnerable products. Even when the NVD supports purl, many (and initially most) CNAs will continue to include CPE names in their new CVE records.

11.   CVE.org will continue to operate as a separate organization, since CVE records are widely used worldwide, not just in the NVD. However, it would be better to move CVE.org to an international organization, perhaps another IANA division that is separate from the GVD. To give CNAs more incentive to include items like CVSS scores and purl/CPE identifiers in their CVE records, it would be better if the CNAs could be paid in some way.

We might start having discussions of this in the bi-weekly SBOM Forum meetings, including today at 1 AM Eastern Time. If you would like to join us, please send me an email. 

f 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] When looking at the NVD’s statistics, it’s important to keep in mind that they have changed their definition of “enrichment” of a CVE record. It used to include adding a CPE name, as well as other items like CVSS score. However, they seem to have conveniently dropped the requirement for a CPE name to be added, for it to be enrichment. While it’s good to have a CVSS score as well, CPE (or hopefully purl in the not-so-distant future) is by far the most important element that needs to be added to a CVE record.

Here’s your chance to advise CVE.org!

I was pleased to see in my LinkedIn feed this morning a post from Alec Summers of MITRE containing a link to a “CVE Data Usage and Satisfaction Survey” which closes on April 4. I was even more pleased when I went to the survey and found it only asks non-wonky questions that should mostly be understandable by casual users of CVE information (which probably includes a large percentage of people in the worldwide cybersecurity community).

The survey is very well thought out. I recommend you fill it out. I especially recommend that you indicate on questions 14, 16 and 19 that you wish to see purl implemented in the CVE Record Format. While purl is present in the format now, it seems that whoever did that thought it’s a format for expressing versions, like semver. Thus, even though someone might enter a purl in a CVE record now, it won’t be usable.

Speaking of purl, I’ve retitled and revised the post I put up a few days ago on the OWASP SBOM Forum’s proposal to enable implementation and use of purl in the CVE “ecosystem”. Please take a look at that.

 

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.

 

Is CVE.org on the chopping block?

I’ve been writing a lot about problems with the National Vulnerability Database (NVD) lately. It didn’t occur to me that there might be similar (although not directly related) problems at CVE.org, which used to be called MITRE. However, I’ve learned that may be the case – and the implications of that would be far more significant than the implications of the NVD’s problems. Since a lot of people don’t understand that these are two different agencies, I’ll provide a Cliff Notes™ summary of them.

CVE.org: Before 1999, software vulnerabilities were identified and classified differently in different communities, e.g., developers working with a particular language. This made it hard to have general discussions about vulnerabilities, since two people could never be sure they were discussing the same vulnerability.

To address this issue, two researchers from the consulting company MITRE proposed a unified vulnerability classification scheme called CVE, which stands for “common vulnerabilities and exposures”. That led to the introduction of the first “CVE list” in 1999. CVE took off quickly, and soon vulnerability disclosures all over the world included CVE numbers.

CVE.org’s most important function is recruiting and managing the CVE Numbering Authorities (CNAs), of which there are 447 today (they include software developers like Microsoft, Oracle, Red Hat, Schneider Electric and HPE, as well as organizations like GitHub and ENISA). These are organizations that are authorized to assign new CVE numbers to vulnerabilities, then create a CVE Record for each vulnerability. The CVE Records are made available in the CVE.org database; they are also forwarded to the NVD and other vulnerability databases that are based on CVE.

CVE.org was formerly known just as MITRE, and many people continue to use that name today. This is not inaccurate, since I believe that 100% of the staff members of CVE.org are MITRE employees. However, those staff members now report to a nonprofit board composed of public and private sector representatives.

The NVD: The NVD also started operating in 1999, although not under that name – it was originally titled “ICAT”. In 2008, NVD initiated the CPE (Common Platform Enumeration) software identifier and started adding “CPE names” to CVE Records from MITRE. I’ve written many times about the shortcomings of CPE, starting with this OWASP SBOM Forum paper in 2022.

The most serious shortcoming recently is that, starting last February, the NVD drastically slowed the process by which they add CPE names to new CVE Records, with the result that in 2024 fewer than half of new CVE Records included a CPE name. Now, the NVD seems to have almost stopped adding them altogether. Since an automated search – e.g., using the search bar - for vulnerabilities that apply to a particular software product will not discover any CVE that does not include a CPE name, this means searches will miss far more than half of the CVEs that might have been identified for that product since February 2024.

To get back to the subject of this blog post, while I have written about the NVD’s problems extensively since they began more than a year ago, I have never even considered the possibility that we should be concerned about CVE.org. That is, until this week, when Steve Springett, leader of the OWASP Dependency Track and CycloneDX projects, emailed me this link to a Reddit chat entitled “What is happening at MITRE?”

The chat can be summarized by saying that many people, both CNAs and bug researchers, have noticed that the time it takes MITRE (CVE.org) to respond to new vulnerability reports has increased substantially in recent months. The people in the chat identified various possible reasons why these slowdowns are occurring, but nobody pointed to some definitive event that might have caused them.

I’m not going to speculate on the reason for the slowdowns, either. However, I want to point out that if CPE.org goes into an extended slowdown like the one at the NVD, the consequences for the software security community, and especially for the vulnerability management community, will be much more serious.

In the NVD’s case, there are ways to get around the fact that a CVE Record doesn’t include a CPE name. One way is to start to implement an alternative software identifier in CVE Records. CPE will probably always be an option for CVE Records, but purl should be another option. In fact, I am proposing a project to accomplish exactly that: make it possible for purls to be included in CVE records and utilized for lookups in CVE-based vulnerability databases.

But what will happen if CVE.org stops performing its most essential function: facilitating the production of vulnerability reports (CVE Records) by CNAs? There is literally no other way that those vulnerabilities will be made public, at least in a standardized manner (i.e., using the CVE Record Format). Of course, software developers will continue to report vulnerabilities to the users of their products, but since those reports aren’t standardized, we’ll be back in the same position as in 1999: there will be many different vulnerability reporting formats, but no common one. Truly automated software vulnerability management will once again be impossible.

What can we do to prevent this from happening? Since nobody in the chat could point to a definite cause of the problem, there’s no way to identify a fix for it. However, I want to point to a general cause, which might show us what the long-term fix is.

The general cause can be summarized by saying, “This is what can happen when government agencies, subject to political control, are responsible for carrying out vital technical functions.” Governments change regularly. Since each government is sovereign and guards its privileges jealously, there’s simply no way to guarantee that any practice or rule that a government agency puts in place today will survive tomorrow, let alone when the next administration takes over and imposes its own practices and rules.

Of course, both the NVD and CVE.org, for all their problems, would never be in anything close to their current form were it not for their both being government agencies; we should be grateful for that. However, maybe the time has come to think bigger than what’s in place today. I would like to propose that:

1.      A new supernational “software vulnerability authority” be created. It will be funded by assessments on governments that want to participate, as well as donations by private sector organizations with a stake in software security (of course, it’s hard to think of any organization today that doesn’t have a stake in software security). The vulnerability authority will include representatives from private and public sector organizations worldwide; it will not have special ties to any one government[i].

2.      The software vulnerability authority will create and operate a new database intended to replace both the NVD and CVE.org databases (this is referred to as “the replacement database” below). This new database will include vulnerabilities identified with CVE numbers and software products identified with CPE names and/or purl identifiers[ii].[iii] The database will include all data that currently exists in the NVD and CVE.org, as week as new CVE Records that are created after the cutover to the new database.

3.      The vulnerability authority will set up an organization like CVE.org that manages organizations that report vulnerabilities (identified in products that the organization developed, products that others developed, or both). These will probably be like the CNAs today, although there would need to be changes to that program. Most importantly, the reporters need to be paid, since today it is hard to incentivize CNAs – all of whom have day jobs - to implement improvements that require a substantial investment of time.

4.      Existing vulnerability databases (such as OSV, OSS Index, GitHub Security Advisories, Python Packaging Advisory Database, VulnCheck, VulnDB, VulDB, etc.[iv]) will be encouraged to continue their current work. These databases will continue to be accessible individually, but there will also be a central “intelligent front end”, through which a user can access datapoints in these databases. The intelligent front end will also allow access to data in the replacement database.

5.      The front end (which I call the “Global Vulnerability Database” or GVD) will manage all interaction between a user and the individual databases that make up the GVD.

6.      The user will be able to enter queries that use one or more vulnerability identifiers (CVE, OSV, GHSA, etc.) and one or more software identifiers (CPE, purl, PyPI Package, etc.). The front end will parse the user’s query into queries to one or more individual vulnerability databases and return all response(s) to the user.

7.      If a user enters a query that contains multiple software identifiers, vulnerability identifiers, or both, the GVD will not attempt to “harmonize” the response by translating one type of identifier into another. For example, if the user requests all vulnerabilities that affect a software product and identifies that product using a CPE name, the GVD will not display any CVE Record that contains just a purl. This is because, in many if not most cases, it is impossible truly to “translate” one identifier into another. If the user knows both the CPE name and the purl for a product, they will learn about all CVEs that affect that product only if they include both identifiers in their query.

Of course, the Global Vulnerability Database is just one alternative for replacing the NVD with a much more robust and universal vulnerability database. When I first started talking about the GVD more than a year ago, it seemed there would be plenty of time to discuss all the nuances, before considering actual deployment.

However, the problems with the NVD, and now possibly with CVE.org, are sending a clear signal that it’s time to start talking about what’s going to replace them. It’s clear that we shouldn’t replace them with another US government-run effort. Been there, done that, got the T-shirt. The replacement needs to be truly global and truly universal.

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] A model for this authority might be IANA, the Internet Assigned Numbers Authority. That organization manages the DNS program worldwide, as well as assignment of IP addresses.

[ii] If one or more other software identifiers become popular in the future, they could be accommodated as well.

[iii] Besides software and firmware, the NVD also displays vulnerabilities found in intelligent devices. That program needs to be substantially rethought, but it needs to be continued in some form - probably in a separate database for devices. The OWASP SBOM Forum’s 2022 white paper described (on pages 12 to 14) a different naming system for devices, based on the existing GTIN and GMN identifiers used in international trade. CPE is not a good identifier for the device itself (meaning the complete set of software and firmware products installed in the device, which in my opinion should be how device vulnerabilities are reported), although individual software products installed in the device can be identified with CPEs.

[iv] The NVD and CVE.org will be discontinued, since all their current data will be included in the replacement database.

A longstanding CVE problem needs to be resolved - along with two others

 

Last December in the annual CNA Workshop run by CVE.org, an important issue was brought up during a presentation by Lisa Olsen of Microsoft. I wrote in my post:

Lisa pointed out that in some CVE reports, the “affected” version of the product refers to the fixed version of the product (i.e., the version to which the patch has been applied), while in other reports (usually from different CNAs), the “affected” version is the unpatched version.

This is a huge difference, since it means some organizations may be applying patches to versions of a product to which the patch has already been applied. Lisa said the new CVE schema will allow the CNA (which is in many cases the developer of the affected product) to indicate which case applies. However, it seems to me there should be a rule: The “affected” product is always the one in which the vulnerability has not been patched.

It's good that the new CVE schema will allow the CNA to indicate whether the vulnerability is found in the patched or the unpatched version of the product, but I was surprised there should be any question about this: After all, only the unpatched version of the product is vulnerable to the CVE, so in my opinion – at least at the time – there should be a rule that the CVE always applies to the unpatched version (frankly, I was surprised that Microsoft seems to take the opposite position). However, I now realize it’s more complicated than that, and there are two other serious questions that come into play here.

The first of those questions is how the supplier will distinguish between the patched and the unpatched versions of the product. I have always assumed that, when a patch is applied to a software product, the version number will automatically change to a new one; for example, if the product follows “semantic versioning”, when a patch is applied to version 5.2.0 of a product, the patched version might be numbered 5.2.1. In this example, when the supplier reports the vulnerability, they will list v5.2.0 in the CVE record, if they follow my rule.

Of course, this is done so that, when a software user learns that version 5.2.0 of a product they use is affected by a new CVE, they will check to see which version they are using. If it’s v5.2.0, they will download and apply the patch. But if it’s v5.2.1, they will know they’re already running the patched version.

However, a lot of software suppliers (both commercial and open source suppliers) don’t change the version number when a patch is applied. Instead, the user needs to do something else to learn what patches are installed on their system. In Microsoft Windows, Windows Update or PowerShell provides this information, but it doesn’t automatically find its way into a CVE record for a product.

Of course, it all software suppliers were required by CVE.org (in the best practices sense, not the regulatory sense) to follow semantic versioning or a similar versioning scheme, it might be possible always to represent the patched version of a product with a different version string – derived by following a particular rule – than the version string used by the unpatched version. Would that solve our problem?

No, it wouldn’t. To understand why, you should review this post in which Bruce (whom I just referred to as “the Director of Project Security of one of the largest software developers in the US”) pointed out that developers often release multiple patches in between two consecutive versions of the product; it is up to the user to decide which of those patches, if any, they wish to apply[i].

This means that, until a new version is published (in which all patches released since the last version are included), the supplier will never know which patches are on a particular user’s system, unless they ask the user to tell them (perhaps during a help desk call). Since a version string that took account of patches would need to represent each of the patches that has been applied since the last version (major or minor) was released, this would make it very difficult to accurately represent all those patches.

To illustrate this problem, suppose there have been five patches released since the last version of a product, conveniently numbered 1,2,3,4, and 5 (of course, real patch numbers are much more complicated). Suppose a user had applied patch numbers 1, 3 and 4, but not 2 and 5. The version string for their instance of the product might be 5.2.1_3_4, or something like that. A user that had just applied patches 3 and 5 would see the version string 5.2.3_5.

Now let’s say the supplier wants to report a new vulnerability in their product. Since they shouldn’t report the vulnerability until they have a patch available for it, let’s suppose this is the sixth patch since the 5.2.0 release of the product. What will the patched version be called? It will have to depend on which of the previous five patches the user has applied. For example, if the user had applied patches 1 and 4, the new version would be called v5.2.1_4_6; if the user had applied patches 2,3, and 4, the new patch would be v5.2.2_3_4_6, etc.

This isn’t just a numbering problem. Since the code for a patch often varies depending on which patches have already been applied, the developer may need to develop a different new patch for each combination of previously applied patches. Bruce calculated that the number of patches[ii] that may be needed is equal to 2 raised to the number of independent patches that have been issued since the last update. In the above example with six patches, this is 2 to the sixth power, or 64. If there are 10 independent patches, the total number of new patches required is 1,024. Needless to say, it isn’t possible to develop this many patches whenever a single new patch is needed.

In other words, my idea that a patched version of a software product could be distinguished from the unpatched version simply by changing a number will not work in practice. Our original question (the one Lisa Olsen discussed in the CNA Workshop in December) was whether the CVE record should refer to the patched or the unpatched version.

The answer is that, since there might be hundreds of “patched versions” applying to a single unpatched version, there is no good way to use versioning as a way to distinguish patched from unpatched products. Of course, this is why patch reports are usually very complicated documents, such as this one from Oracle (chosen at random).

Naturally, this is a disappointment. I originally thought the problem Lisa brought up could be easily solved, but that’s far from being the case. So, how can it be solved? Like almost every complicated problem, it requires people with a stake in solving the problem to get together (presumably virtually) to work out an acceptable solution. It won’t be a thing of beauty, of course, but hopefully it will at least be usable.

Who are the people with a stake in this problem and how will they get together? In my previous post, I called for a proof of concept for introducing purl identifiers into the CVE ecosystem. That PoC will gather stakeholders in the vulnerability management process, including software developers, CNAs, and vulnerability database operators. Since one of the objectives of the PoC will be to identify new or changed “rules of the road” for reporting new vulnerabilities in CVE records, and since this question very much involves one of those rules of the road, it would be appropriate to include a discussion (and hopefully resolution) of this problem in the proof of concept.

I will put this in the to-do list for the PoC. Please join us for this project. Email me at tom@tomalrich.com to discuss participating in the project (or at least the initial planning phase) and/or financially supporting the project by donating to OWASP.

 

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] Sometimes, developers release “cumulative” patches, meaning one patch will include all previous patches. However, suppose a supplier releases a cumulative patch C, which includes patches A and B. A user doesn’t want to apply Patch A (because of a possible incompatibility with their instance of the product), but they’d like to apply C. Obviously, they can’t do that. This is one reason why cumulative patches aren’t the norm in the software industry.

[ii] The 2023 post was about SBOMs, but the argument applies equally to patches.

Implementing purl in the CVE ecosystem

As discussed in this recent blog post, software vulnerability management is facing a serious problem: The National Vulnerability Database (NVD) seems to be seriously neglecting one of its two primary responsibilities: adding “CPE names” to new CVE records.

This leads to two problems that need to be addressed as soon as possible.

Part I: The first problem

· Software users need to be able to learn about vulnerabilities that have been reported in the software they use. They do this by searching a software vulnerability database.

·       The National Vulnerability Database (NVD) is by far the most widely used vulnerability database in the world. However, just learning about a new software vulnerability does not help a user, unless they know what product or products are affected by the vulnerability.

·       In the NVD, vulnerabilities are identified in CVE records using a format like “CVE-2024-12345”. Products that are affected by a CVE should be identified in the CVE record, using a machine readable “CPE name” like “cpe:2.3:a:microsoft:internet_explorer:8.0.6001:beta:*:*:*:*:*:* ”.  

·       Currently, NVD contractors are responsible for adding CPE names to new CVE records. Before February 2024, this was almost always done within a few days of when the NVD received the CVE record.

·       If a CVE record does not contain a CPE name for a software product affected by the vulnerability described in the text of the record, a user searching for vulnerabilities that have been identified in the product will not learn it is affected by that CVE.

·       The NVD’s problem is that, starting on February 12, 2024, the number of CPE names it created dropped drastically. As a result, about 55% of new CVE records in 2024 were never given a CPE name. This means the product(s) affected by that CVE are invisible to a search. Various observers have pointed out that in 2025, the problem is getting even worse, since only about 25% of new CVE Records contain a CPE name. As of this writing (the end of March 2025), there is a serious question whether the NVD is creating new CPE names at all.

·       This means that any search for a particular product in the NVD is more likely than not to miss any vulnerabilities that have been reported for that product since February 2024, making NVD searches more and more useless – as well as misleading – as time goes on.

·       What other vulnerability databases are there, besides the NVD? For open source software products, the answer is “a lot”. These include OSS Index, OSV, GitHub Security Advisories and others; in fact, a software user is more likely to learn about vulnerabilities that apply to open source software products (or open source components in an SBOM) in these databases than in the NVD.

·       However, for commercial software products, there is currently only one vulnerability database: the NVD[i]. Because the NVD can no longer be called reliable, this means there is currently no reliable source of vulnerability data for commercial software products. Obviously, this isn’t a good thing, given how dependent business and government organizations are on commercial software.

·       When will this problem be fixed? If this question asks when CPE names will be added to all the over 30,000 “CPE-less” CVE records currently in the NVD’s backlog, the answer is “probably never”. Currently, the best that can be hoped for is to slow the rate of growth of the backlog.

·       Since the CPE backlog may never go away, what measures can be taken in the longer term? There isn’t much question: CVE records can no longer be restricted to containing CPE identifiers. While CPE should continue to be one option for new CVE records, it should no longer be the only one. The best alternative is purl.[i]

·       If purl were implemented in the CVE record format, it would immediately improve identification of open source products, since purl has – in only about eight years – become a major software identifier used in open source vulnerability databases.

·       The most important feature of purl is that the user never has to look up the purl for a product before they search for the product in a vulnerability database. This is because they should always be able to create the purl for a product by using information they already have. This includes the package manager from which they downloaded the software, as well as the package name and version string in that package manager.

·       Since each purl is globally unique, a purl for an affected product in a CVE record should always match a purl created by a software user before they search for the product in a vulnerability database. This means that searches using purl will have a high success rate.

How can we address the first problem in Part I of the project? 

Introducing purl into the CVE ecosystem requires making it possible for CVE Numbering Authorities (CNAs) to designate software products in CVE records using purls. CNAs are mostly larger software developers and organizations like GitHub; they are responsible for reporting vulnerabilities to CVE.org using the CVE Record Format.

Three tasks are required to address the first problem. In each of these tasks, we will coordinate with the CVE.org Quality Working Group.

A.      Develop a new version of the CVE Record Format to accommodate use of purl and submit it as a pull request to CVE.org. The SBOM Forum will work with the CVE.org Quality Working Group (QWG) and the Python Foundation to accomplish this goal.

B.      Develop plans for an end-to-end proof of concept for use of purl in the CVE ecosystem.

C.     Conduct that proof of concept. The PoC will involve software suppliers, end user organizations, CVE Numbering Authorities (CNAs) and vulnerability database operators.

Part II: The second problem

·       Today, purl can only be used to identify open source software in package managers, not commercial software. Since most private and government organizations utilize commercial software to run their businesses, it is important that purl be expanded to identify commercial, as well as open source, software products. In 2022, the OWASP SBOM Forum suggested[iii] a way to fix this problem by having a supplier create a “SWID tag” for each of their products. A new “type” called SWID was developed and implemented in purl.

·       A SWID tag is a small document containing 5-10 pieces of metadata about a software product. These pieces of information can be used to create the purl for the product, which will always be globally unique.

·       The only three mandatory fields for a purl using the SWID type are “name”, “version” and “tagId”. Note that “tagId” can be almost anything. For example, it could be the URL from which the product is downloaded.

·       To illustrate this, the purl for Fedora version 29 is “pkg:swid/Fedora@29?tag_id=org.fedoraproject.Fedora-29”. Note that every purl starts with “pkg:” followed by the type. For open source software, the type usually indicates the package manager or other repository – for example, “NPM” for Node NPM packages and “maven” for Maven JARs and related artifacts. However, for commercial software, the type will normally be SWID.

·       The supplier will usually make both the SWID tags and the purls for their products available on their website or by other means. If a user wants to look up a product in a vulnerability database, they can download the purl for it, if that is available; otherwise, they can download the SWID tag and use that to create the purl (of course, various tools will automate this process). Neither the purl nor the SWID tag will need to change until the product is upgraded to a new version.

·       As in the case of purls for open source software products, the purl included in the CVE record for a commercial product should always match the purl a user creates when they want to search for that product; this is because both purls will be based on the contents of the same SWID tag. 

How can we address the second problem in Part II of the project?

We can address the second problem – purls current lack of support for commercial software products - with three tasks. To accomplish Part II, we will work with a group of industry participants, including commercial software developers, CNAs, and vulnerability database operators.

A.      Develop “rules of the road” for production, distribution, and use of SWID tags to allow purl to identify commercial software.

B.      Test those rules in a small-scale proof of concept. In that PoC,

                                        i.               A supplier will create SWID tags (perhaps using this tool) for certain products and make them available to their customers;

                                      ii.               CNAs will create test CVE records containing those purls to report test “vulnerabilities” in their products[v];

                                   iii.               One or more vulnerability databases (that support both CVE and purl) will ingest the test CVE records; and

                                   iv.               End users will utilize purls created from the SWID tags to search the vulnerability databases. If all the CVEs that were recorded for a product are revealed when the user searches using the product’s purl, the PoC is successful.

C.     Develop educational webinars and videos on use of purl in the CVE Record Format for CNAs and other participants in the CVE ecosystem.

Note: While Part 2 of the project follows Part 1 in this document, it is not necessary that this should be done when the project is executed. This is because nothing in Part 1 is an absolute prerequisite for accomplishing Part 2. The project might be significantly accelerated if Parts 1 and 2 could be accomplished at the same time.

The goal of Part 1 is to conduct a proof of concept to demonstrate how purl, as it is used today, can be incorporated as an optional software identifier in the CVE ecosystem. Since purl currently is used mostly to identify open source software found in package managers, that will be its use when it becomes an option in CVE Records.

However, the goal of Part 2 is to allow purl to become an identifier for commercial software products by having commercial developers create SWID tags to carry  metadata for their product; users searching for vulnerabilities in a commercial product that they own can utilize the product’s SWID tag to create a purl for it. This should always exactly match the purl used by the CNA when they reported the vulnerability in a new CVE Record (because both purls will be based on the same SWID tag).

The goal of Part 2 will be to develop “rules of the road” for creating and using SWID tags and the purls based on them, as well as test these in a small-scale proof of concept. Because SWID is just one of hundreds of purl types and the types can be used interchangeably, no changes should be required to the CVE Record Format or any other component of the CVE ecosystem.

Therefore, if funding permits, Part 2 of this project should be executed at the same time as Part 1. For example, while the proof of concept in Part 1 Step C is being executed, either (or both) steps D and E of Part 2 could be executed. Since Part 1 might itself require nine months to one year, starting both parts simultaneously could save up to a year of total project time.

One reason why this should be considered is that as of late March 2025, the NVD is not creating new CPE names in anywhere near the volume required to reduce their backlog of “unenriched” CVE Records, let alone eliminate it. While there are alternate vulnerability databases for open source software (almost all based on purl), there are no vulnerability databases for commercial software that are not themselves based on the NVD.

As previously stated, this means there is no reliable vulnerability database for commercial software products today. Given that private enterprises and government agencies mainly utilize commercial software, this is a serious problem. The sooner that purls based on SWID tags can be used in new CVE Records, the sooner that users of commercial software products will be made fully aware of the risks they face due to recently identified vulnerabilities.

 

Conclusion

It is possible that the National Vulnerability Database may no longer exist at all soon. However, no matter what happens, it is clear there needs to be an alternate software identifier besides CPE available to CNAs and software end users. While there are one or two experimental alternatives (such as OmniBOR), purl is already in heavy use. For example, the open source software composition analysis (SCA) tool Dependency Track alone is used over 20 million times every day to look up a dependency from a software bill of materials (SBOM) in the OSS Index vulnerability database, which is based on purl.

Purl’s availability in the CVE record format will quickly make identification of open source software much easier and more accurate in the NVD and other vulnerability databases based on CVE. And, when the policies and procedures for use of the SWID purl type have been worked out and tested in a proof of concept, identification of commercial software products in the same databases will be much easier, as well as much more accurate.

Of course, it will probably be 1-2 years before purl is in widespread use in the CVE ecosystem. But there’s no excuse for waiting any longer; two years in the future will still be two years in the future six months from now. The six tasks (A – F) listed above are mostly non-technical; they mainly require getting agreement among a group of participants in the CVE ecosystem.

The OWASP SBOM Forum will be pleased to lead this effort; we will start out with an initial project to perform the first two Part 1 tasks: development of plans for the proof of concept and identification of changes to the CVE record format that are required to accommodate purl.

Anyone interested in contributing their time and/or resources to this project should contact Tom Alrich at tom@tomalrich.com. Donations to OWASP of $1,000 and up can be “restricted” to use by the SBOM Forum. OWASP is a 501(c)(3) nonprofit organization. We welcome all contributions. 

---

[i] There are several commercial vulnerability databases that are based on the NVD; these include the data currently in the NVD (which can be downloaded in about ten minutes). That data has been augmented and “cleaned up”. These databases are all trying to remedy the NVD’s current shortfalls in various ways. However, none of them have the resources to do more than try their best to fill the most serious gaps.