Whose side is the NVD on, anyway?

Some of the most interesting things I learn while writing this blog are stories I hear that aren’t the subject of the post I was working on when I heard them – but which prove to be every bit as interesting  as the post itself. This happened with my last post, in which I paraphrased an email from Bruce Lowenthal, Senior Director of Product Security for Oracle.

Before I go into detail on what Bruce said in his email, I want to make some background points for people who haven’t been following the NVD controversy as much as some of us have:

1.      CVE records are created by CVE Numbering Authorities (CNAs); these are organizations (over 400 today) that voluntarily report new vulnerabilities (CVEs) to the CVE Program. The most prolific CNAs are commercial software developers like Oracle, Microsoft, Schneider Electric, ServiceNow and HPE; these organizations report newly identified vulnerabilities in their own products. Other important CNAs include organizations like GitHub, Red Hat and the Linux Kernel; they mostly report vulnerabilities in open source projects.

2.      CPE names are machine-readable identifiers for software products. The NVD identifies vulnerable software products using CPE names. A CPE name includes fields like the name of the product, its version number, the vendor name, and others. Note that a software product cannot be identified through an automated search in the NVD (or another vulnerability database that is based on CPE) unless it has a CPE name. Given that there are now more than 300,000 CVE records in the NVD, it is no longer practical to rely on text searches to identify vulnerable products.

3.      Since software products and software vendors are referred to by many different names, by different parties and at different lifecycle phases, the NVD has always tried to maintain tight control of CPE names. Moreover, it has discouraged other parties (including the software developers themselves) from creating their own CPE names.

4.      When a CNA creates a new CVE record and submits it to the CVE.org database, they include a textual description of one or more products that are vulnerable to the new CVE, for example, “Product ABC version 2.7 from XYZ Corporation”. However, the CNA doesn’t normally create a new CPE name for the product, in deference to the NVD’s wishes.

5.      The NVD regularly downloads new CVE records from CVE.org and incorporates them into the NVD database. Of course, at that point the new records do not usually include CPE names.

6.      Until February 2024, an NVD staff member (usually a contractor to NIST) almost always created a CPE name for a vulnerable product described in a new CVE record within a few days of the record’s first appearance in the NVD. As already mentioned, that NVD staff member might use one of many product names, e.g., “Microsoft Word”, “Microsoft Office Word”, “Word”, “Office 365 Word”, “Microsoft Word Swahili Edition”, as well as one of many vendor names, such as “Microsoft”, “Microsoft, Inc.”, Microsoft Inc”, “Microsoft EMEA”, “Microsoft APAC”, etc. The NVD has never published a formal methodology for choosing the product or vendor name to be included in a new CPE name. Thus, it is close to impossible to predict the product or vendor name that was included in the CPE name for a product, meaning it is very hard to predict the CPE name itself.

7.      For reasons that have never been adequately explained, the NVD stopped regularly creating CPE names for all new CVE records in February 2024. The result of this problem is that fewer than half of the new CVE records that have appeared in the NVD since February 2024 have CPE names. This means those records are essentially invisible to automated searches in the NVD (for example, searches using the command line), since the user searching for newly identified vulnerabilities in a software product will have to guess which product and vendor names were included in the CPE name for the product. This means almost any vulnerability search in the NVD will require some “manual” steps; it can never be fully automated.

8.      As my previous post pointed out, this is one of the main reasons why software end users are forced to devote so many resources to vulnerability management today.

In his email to me last week (which I had solicited), Bruce wrote that since last November, the NVD has not made it a priority to assign CPEs to newly identified CVE records within a few days, as they almost always did in the past. Instead, they now usually assign CPEs to CVE records that are already over a month old.  This makes no sense; CPE assignment should focus on CVEs published less than a month ago, not more than a month ago. And it should not focus at all on CVE records published more than three months ago.

And yet, the NVD seems to be focusing mostly on records that are more than three months old (for example, the NVD is still adding CPEs to records first published in 2024), while not focusing much at all on records that appeared in the current month. In fact, since last November, Bruce says there hasn't been a single month in which the NVD has assigned a CPE to even 50% of the CVE records published in that month.

For example, in June 2025 the NVD assigned a CPE to 194 CVE records that were originally published more than three months previously, but they only assigned a CPE to 356 CVEs that were published in May or June. It was simply a waste of time for the NVD to patch the 194 old records, when at least 5,400 new CVEs were published in May or June, that still don’t have a CPE name.

Why is this important? In my previous post, I went on to say (with some rephrasing), “Bruce points out that this is an almost totally useless exercise, since software suppliers are much more likely to have patched older vulnerabilities than recently identified ones. If the software supplier releases new patches within a few weeks of the vulnerability being discovered and the user applies those patches quickly, most CVE records that are more than a month old are likely to be irrelevant. If a user organization has already patched a vulnerability, it obviously no longer poses a risk to the organization.”

In other words, the NVD now seems to be waiting to attach a CPE to a CVE record when the record is so old (3 months or older) that doing this won’t be very helpful at all. They do this instead of making the extra effort required to create the new CPE shortly after the CVE record is introduced, as they almost always did before February 2024. How does this make sense?

In his email to me, Bruce went beyond the statements I paraphrased above. Here are the other statements he made (with some paraphrasing). I’ve added my interpretations in italics:

1. “NVD has not assigned CPEs to CVEs published in any month after November of last year.” Starting last November, the NVD seems to have stopped even trying to add CPE names to CVE records in the first month after the new record appears in the NVD. In other words, if they add a CPE name at all, they now do so more than a month after the new CVE record has appeared in the NVD.
2. “NVD continues to assign CPEs to old CVEs…No one cares if CPEs are assigned to CVEs published in 2024.  Assigning a CPE name to a CVE published in 2024, in preference to a CVE published in the most recent month or two, is a waste of time and resources.”  The reason why Bruce says this is that even very slow vendors try to patch severe vulnerabilities within 2-3 months. Thus, if their customers apply the patches soon after they receive them, older vulnerabilities no longer pose a significant threat.
3. However, newly identified vulnerabilities are sometimes not patched for a few months, either because the vendor hasn’t issued the patch or the customer hasn’t applied it. This means that customers need to be reminded about recently identified vulnerabilities in the products they use. Yet, it is precisely these vulnerabilities that customers aren’t being reminded about, since the lack of CPE names in recent CVE records means that customer searches won’t identify those CVEs as posing a problem to them.
4. “Many people expect vendors to upgrade products with third party security fixes within a couple of weeks or a month.  However, because the NVD is now delaying assignment of CPE names to new CVE reports, vendors are struggling to issue some patches within three months of when the new report appeared.”
5. Bruce’s point here is that a lot of people aren’t aware that software vendors often release patches created by third parties for a library that the vendor included in one of their products. If that library is affected by a recent CVE that has been reported, but that record doesn’t include a CPE name, the vendor may not learn that the library is affected by the new CVE; therefore, they won’t release a patch until after the NVD has created the CPE name for the vulnerable version of the library and added it to the CVE record. And that may be several months after the vulnerability was reported.

When the NVD started having their problems in February 2024, a lot of people in the vulnerability management community reflexively defended the NVD, because of their general good experiences with it; I was one of those people at first. However, as time dragged on and the NVD never provided a good explanation for their problems – beyond the fact that, like all of us, they would like to have more money – I began to lose patience with them. I especially lost patience when they once or twice announced that they had received more money and would have the problem licked by a ridiculously optimistic date, such as September 30, 2024. As already stated, their problem has only gotten worse, not better.

However, I must admit that I find the NVD’s current actions to be inexplicable. They have finally begun to add more CPE names to CPE records than they did earlier this year, but they seem to be restricting themselves to doing this for records that are too old to matter anymore. Meanwhile, they are neglecting the CVE records that do matter: the ones that are less than 30 days old.   

NIST recently announced they are “auditing” the NVD. I hope they’ll point out in their audit findings that just focusing on old records that don’t matter anymore, rather than new records that do matter, doesn’t help anybody.

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 put up a paywall and 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.