News from the folks at CVE.org

This week, Andrey Lukashenkov of Vulners posted in LinkedIn this link to 15 videos from CVE.org’s annual CNA workshop, which was held at the beginning of December. I decided there might be one or two videos I would like to watch, but I ended up watching about half of them, plus reading the meeting notes and the session summaries.  

I won’t try to summarize the sessions that I watched. If any of the session topics interest you, I recommend you watch the video, since the meeting notes and session summaries just scratch the surface of what was said. However, I will repeat some interesting statements I heard, and I’ll explain why I found them so interesting – in my next post.

However, since I realize that many readers don’t know much about CNAs, CVEs, CPEs, etc., I’ll provide a relatively short introduction to this world-unto-itself now:

1.      You probably know that a CVE number (e.g., CVE-2024-9680) designates a vulnerability. Where do CVE’s come from (by the way, if you want to know what CVE stands for, it’s “common vulnerabilities and exposures”. But I’ve been told that today CVE is just NBI – nothing but initials)?

2.      Many people think of a CVE as something that has always been present in a software product. It is there because one of the original developers made a mistake. It is only being reported now because nobody discovered it until recently.

3.      In fact, new CVEs are discovered all the time, and they’re discovered in code that was previously thought to be completely benign. In other words, hundreds of experienced eyes previously looked at the code in question and saw nothing wrong with it. But one day, some intrepid soul realized these seemingly innocuous lines of code were in fact a vulnerability that needed to be reported to the world.

4.      Here’s a short quiz: Who do you think most vulnerabilities are reported by: a) an independent researcher, or b) the developer of the software?

5.      If you said “b”, you’re correct! Most vulnerabilities are identified and reported by the developer of the software; moreover, a small number of the largest developers report the great majority of new vulnerabilities. Far from hiding vulnerabilities, the developers are taking the lead in rooting them out and exposing them to the light of day. Of course, this isn’t to say there aren’t a lot of developers who try to hide vulnerabilities. But I suspect that any developer who does that today is setting themselves up for failure, not success. Most software users understand that vulnerabilities need to be found and fixed, not swept under the rug.

6.      CVE.org is part of the US Department of Homeland Security (DHS). CISA is also part of DHS; in fact, CVE.org’s budget is funded by CISA.

7.      CVE.org used to be called simply “MITRE”, since from its inception CVE has been a project contracted to the MITRE Corporation (in fact, MITRE created the CVE system in 1999). Today, an independent board of government and private industry representatives governs the CVE program.

8.      New CVEs are reported by public and private (mostly private) organizations that are called CVE Numbering Authorities or CNAs; today, there are over 400 CNAs. The majority of CVEs are reported by CNAs that are large software developers, including Microsoft, Oracle, Red Hat, HPE, Schneider Electric, etc. – although many smaller developers, nonprofits and governmental organizations are CNAs as well.

9.      When a person or organization that is not a CNA wishes to report a vulnerability, they can request that a CNA prepare the report for them. They need to first go to a CNA that has the organization within its scope – e.g., a country, an industry, etc. For example, any project on GitHub can report a vulnerability to GitHub, which is a CNA. If an organization can’t find a CNA that way, they can go to one of the “CNAs of Last Resort”, including CISA (for ICS) and MITRE (for everything else).

10.   The CNA creates a CVE ID (aka “CVE number”) for the vulnerability and submits the report to CVE.org, where it becomes a CVE record and is included in the CVE.org database. At this point, the CVE record does not usually contain a “CPE name”. While CPE stands for “common platform enumeration”, that phrase means very little today. For the moment, it suffices to say that CPE is the oldest (over two decades) machine-readable software identifier. Because one software product can have different common names in many different contexts, automated vulnerability management is only possible if each product has a single identifier.

11.   Now the CVE record goes to the National Vulnerability Database (NVD), which is operated by the National Institute of Standards and Technology (NIST), an agency of the US Department of Commerce. It also goes to any other database that accommodates CVE and CPE. NIST is an agency of the US Department of Commerce.

12.   Until February of 2024, an NVD contractor at this point quickly created a CVSS score, identified one or more CWEs (common weakness enumeration), and created a CPE name for any product named in the text of the CVE record. However, starting on February 12, that process broke down. As of December 2024, the NVD has added these items to fewer than half of the CVE reports that came to it during the year (about 16,000 of 37,000 total CVE records).

While there is a lot to be said about missing CVSS scores and CWEs, the primary concern of most people involved in software vulnerability management is the lack of CPE names on CVE records. This is because, even though CVE records normally include a textual description of the affected products, an automated search for vulnerabilities applicable to a particular product (the normal use case for software vulnerability databases like the NVD) can only identify the product if it has a machine-readable identifier.

In other words, as of today, an automated search of the NVD for a software product will on average miss more than half of the CVEs that have been reported for the product in 2024. Of course, this is not a good situation. I’ll discuss this further in the next post. 

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.

My book, Introduction to SBOM and VEX, is available here!