The CNAs need to step up

I started the OWASP Vulnerability Database Working Group earlier this year to address questions of how users of vulnerability databases can move forward, since it is clear it’s no longer sufficient to rely on the National Vulnerability Database (NVD) as their sole source of software vulnerability data.

The biggest reason why the NVD can no longer be relied on is that starting on February 12 of this year, they almost completely stopped performing perhaps their most important function: “enriching” the contents of CVE reports gathered by cve.org. CVE.org is the organization (part of DHS) that is by far the largest source of vulnerability information in the world (the cve.org database used to be called “MITRE”, since it’s operated by consultants from MITRE Corporation, under the direction of the nonprofit cve.org board).

Most people involved in software vulnerability management (including me until a year or two ago) start off with the assumption that CVEs kind of magically fall from the sky. That is, an astute researcher learns of a vulnerability in software they run across and reports those to “the government”, which enters these as new CVEs. In other words, it’s a small army of researchers that “blows the whistle” on software developers, who would prefer that their customers not learn of vulnerabilities in the software they use.

In fact, it’s almost exactly the opposite: Most software vulnerabilities are reported by the developer of the software. They do this so their customers can learn of the risks they face as users. The customers can then take steps to mitigate those risks, usually by applying a patch supplied by the developer.

Many developers (probably around 300) have taken the additional step of becoming a CVE numbering authority (CNA); CNAs are organizations that are authorized to file CVE reports. They file them on behalf of their own software, but they also have a “scope” of other developers (e.g., developers in a particular industry or country) whom they can assist in filing reports of vulnerabilities in their software. If a developer can’t get any other CNA to help them file a CVE report, the “CNA of last resort” is usually MITRE; in some cases, it is another organization like CISA.

A CVE report is created by a CNA and submitted to CVE.org, where (if approved) it becomes part of the CVE.org database. The report then “flows through” that database to the NVD. Before the NVD’s problems started in February, the next step would always be that an NVD staff member (who would always be a NIST employee, if not a contractor) would add two items to the report: the CVSS score, one or more applicable CWEs, and a CPE name for each product described in the text of the report.

For example, in this report, CWE (Common Weakness Enumeration) 434, CVSS base score 7.5, and CPE name “cpe:2.3:a:smartbear:zephyr_enterprise:*:*:*:*:*:*:*:*” were all probably assigned by a NIST/NVD staff member. But the CVE number, CVE-20203-22890, as well as any additional text was entered by the CNA.

You might wonder why the CNA wouldn’t enter all the information themselves. After all:

1.      CPE is based on the name of the product and the vendor. Since the CNA is either the vendor itself or working with the vendor, wouldn’t it make sense that they would enter both pieces of information?

2.      Given that the CNA usually discovered the vulnerability in the first place, wouldn’t it make sense for them to enter the CVSS score as well as the CWE (which identifies a particular weakness that led to the vulnerability)?

In other words, why should a NIST/NVD staff member enter all three of these items, when the CNA is much better qualified to enter them? I have heard that in some cases, the NVD will overwrite what the CNA entered (e.g., the CVSS score), since for some reason the NVD thinks it knows more. But I also know that in many other cases, the NVD enters the information because the CNA didn’t enter it (although I’ve also been told by some CNAs that they don’t bother to fill in fields when they’re sure the NVD will overwrite what they wrote).

In any case, it seems that after February 12, the NVD in large part abandoned its former role of entering CWE, CVSS and CPE in CVE reports. The most important of these three is CPE. After all, CPE is a machine-readable identifier for a software product that is affected by the vulnerability described in the CVE report. It does nobody any good to learn there is a scary new vulnerability out there, but not to know what software it affects.

Of course, since every CVE report includes a textual description of the affected product; the can always read that text. How hard can that be? It isn’t hard if the user’s purpose is just to obtain information on one vulnerability or a small number of vulnerabilities. But what if the user is an organization that operates 1,000 software products, and they want to check every day to learn what new vulnerabilities may apply to them?

In that case, the organization will need to do a string search through a vulnerability database (I would have said the NVD six months ago, but it would most likely need to be another database today – with a check of the NVD as a backup) for each of those 1,000 products. With a lot of luck, they will find all CVE reports that contain that text string. Assuming the version string matches as well, they will learn about new vulnerabilities that apply to one product that they utilize. Then, they repeat this process 999 times (although almost certainly much more often than that), and they’ll have achieved their goal. Tomorrow, they’ll need to repeat this whole process. What could be easier?

This is why there needs to be a CPE name for every product described in the CVE report. And it’s also why I was disappointed to learn in the OWASP Vulnerability Database Working Group meeting this week that it seems most CVE reports still don’t have CPE names on them.

In other words, the CNAs can no longer blame the fact that there’s no CPE name in a report on the NVD by saying something like, “They always assign the CPE name, not us.” The CNAs know the NVD has fallen way behind on “enriching” the CVE reports with CPE names. Moreover, they also know that CVE.org is now urging CNAs to add both CPA name(s) and a CVSS score to every CVE report. Yet, they mostly aren’t adding them now, meaning that a lot of current CVE information is close to useless.

How does this situation get fixed? It can’t be by docking the CNA’s pay, since they’re all volunteers. I’m sure more training will help, and maybe that’s the solution. What would be neat would be if the CNAs could be trained on creating purl identifiers, which are now supported in CVE reports created using the v5.1 specification. But purls are only available now for open source software, and the databases that support CVE will need to be modified to allow searches on purls.

Purl is the identifier of the future, as evidenced by the fact that it has completely conquered the world of open source vulnerability databases. Moreover, there are ways that purl could be extended to cover commercial – or “closed source” – software as well. One possibility is described in the OWASP SBOM Forum’s white paper on software naming from 2022, but there are other ways to do this.

But for the time being, CPE is the only game in town. We need to get that to work. Without the ability to look up vulnerabilities in an automated process, a lot of what developers and end users do to secure software today becomes useless.

Any opinions expressed in this blog post are strictly mine and are not necessarily shared by any of the clients of Tom Alrich LLC. If you would like to comment on what you have read here, I would love to hear from you. Please email me at tom@tomalrich.com.

I lead the OWASP SBOM Forum, which works to understand and address issues like what’s discussed in this post; please email me to learn more about what we do or to join us. You can also support our work through easy directed donations to OWASP, a 501(c)(3) nonprofit. Email me to discuss that.

My book "Introduction to SBOM and VEX" is now available in paperback and Kindle versions! For background on the book and the link to order it, see this post.