Given how important CVEs are for cybersecurity, it’s at first surprising how few people, outside of those who make their living in vulnerability management or remediation, have a good understanding of where and how CVE records are created and managed. My guess is this is because most users of CVEs think of them as just something that’s part of the landscape, like roads: We don’t have to think about who made them and how they did it; we just use them. But as we all learned in April 2025, we can’t take CVEs for granted.
Not more than a few years ago, I was like most people who utilize CVE information all the time: I had no more idea of where CVEs came from than if the Vulnerability Fairy created CVE records. There’s no “CVE for Dummies™” book that puts everything you need to know in a few pages, so I’ve pieced together what I know about CVE over the past few years from a variety of sources.
Since I write about vulnerabilities regularly in my blog but I always feel bad when I use terms that I’m sure people don’t understand well (e.g., CVE, CNA, CPE, PURL, NVD), I’m writing this post to serve as an “anchor” for future posts. Because the world of CVE is always changing, I will try to keep this post up to date with new developments.
Where do vulnerabilities come from, Daddy?
You probably know that a CVE number (e.g., CVE-2026-12345) designates a vulnerability, which is why it is called a “vulnerability identifier” (CVE stands for “Common Vulnerabilities and Exposures”). There are many vulnerability identifiers, such as GitHub Security Advisories (GHSA), but CVE is by far the most widely used vulnerability identifier worldwide. Where do CVE’s come from?
Here’s a short quiz: Who do you think reports the overwhelming majority of software vulnerabilities in commercial software: A) independent researchers (good guys), B) evil hackers (bad guys), or C) the developer of the software? If you said “C”, you’re correct! As far as commercial software is concerned, vulnerabilities are usually identified and reported by the developer of the software; moreover, a small number of the largest developers report the great majority of new vulnerabilities.[i]
Far from hiding vulnerabilities, 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 developers who try to hide vulnerabilities. But I suspect that any developer who does that today is setting themselves up for failure, not success. I say this because, if the developer’s software is hacked and they get sued by a bunch of unhappy customers - and if the plaintiffs learn that the developer almost never (or literally never) reports vulnerabilities they find in their software - the developer might not be happy with the outcome of their court case. That is, if they’re even still in business afterwards.
Before I go further, you may wonder whether developers are stupid, since they’re usually still identifying new vulnerabilities in their products long after they develop them. Wouldn’t the world be a better place if the developers just followed secure software development practices to begin with? That way, their software will be vulnerability-free from the start, right? Is it hard to do that?
In fact, developing vulnerability-free software is not only hard, but it’s literally impossible. That’s because even though most developers do their best to identify and fix vulnerabilities they identify in their code before they ship their product (if for no other reason than because they know that a lot of their customers will scan the product for vulnerabilities before starting to use it), a determined individual - usually a member of either Group A or Group B - could fairly easily find multiple vulnerabilities that were unknown when the code was originally written. Thus, no software is ever truly “vulnerability free”. Anyone who tells you otherwise is wrong.
New vulnerabilities are discovered all the time, and they’re discovered in code that was previously thought to be completely benign. In other words, lots of pairs of experienced eyes previously looked at a piece of code 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; without any change to the code, the software went from being “vulnerability-free” to “vulnerable”.
The CVE Program
The CVE Program creates and manages the CVE Records that identify software vulnerabilities – so that two people discussing a vulnerability can be sure they are discussing the same thing. The program used to be called simply “MITRE”, since from its inception CVE has been a project contracted to the MITRE Corporation (in fact, MITRE first described their idea for CVE in 1999). Today, an independent board of government and private industry representatives governs the CVE Program, although MITRE staffs and runs the program.
Here are the steps by which a new CVE record is created in the CVE Program:
1. New CVEs are reported by public and private organizations that are called CVE Numbering Authorities or CNAs; today, there are over 525 CNAs. Each CNA has a scope, which can be a country, an industry, etc. When a person or organization that is not a CNA wishes to report a vulnerability, they can approach a CNA that has the organization within its scope. For example, any project on GitHub can report a vulnerability to GitHub, which is a CNA; GitHub will assign a CVE number to the vulnerability and submit the report for approval by the CVE program. If an organization can’t find a CNA that way, they can go to one of the “CNAs of Last Resort”. Currently, these are CISA (for industrial control systems) and MITRE (for everything else).
2. 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 (although it needs to be approved first. Many proposed CVEs are rejected, for various reasons). At this point, the CVE record always includes a textual description of the product(s) in which the vulnerability is found. However, it does not usually contain a “CPE name” (CPE stands for “common platform enumeration”, although that phrase means little today); see below for further discussion of CPE.
3. 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 vulnerability database that supports both CVE and CPE (there are at least six or seven of these databases. They all include everything currently in the NVD, plus additional features and data offerings).
4. Until 2024, after a new CVE record reached the NVD, an NVD contractor almost always “enriched” the CVE record by a) creating and adding a CVSS Base Score, b) identifying one or more CWEs (common weakness enumeration) that apply to the vulnerability, and c) creating a CPE name[ii] for any product described as vulnerable in the text of the CVE record.
5. However, starting in February 2024, that process broke down, with the result that currently a large percentage of CVE records do not contain a CPE name; that percentage is growing quickly, following an announcement by NIST in January 2026 that they were going to significantly restrict the number of CVEs they enrich going forward (see this post for more information on this subject). This is a big problem, because a CVE record that does not contain either a CPE name or a PURL identifier is usually invisible to a command line- or API-based search in the NVD. This means that, when a user searches the NVD for a particular product and version number, they will not be notified that CVE-2026-12345 has been reported in that product, even if the product/version was mentioned as vulnerable in the text of the report for CVE-2026-12345. This may potentially leave the user with a false sense of security.
Tom Alrich’s Blog, too is a reader-supported publication. You can view new posts for three months after they come out by becoming a free subscriber. You can also access all of my 1300 existing posts dating back to 2013, as well as support my work, by becoming a paid subscriber for $30 for one year (and if you feel so inclined, you can donate more than that or become a founding subscriber for $100). Whether free or paid, please subscribe.
If you would like to comment on what you have read here, I would love to hear from you. Please comment in my chat or email me at [email protected].
[i] These results are different for open source software (OSS), since currently most OSS vulnerabilities are reported by third parties including Patchstack, VulDB, the Linux kernel, MITRE and GitHub. Of course, commercial software is compiled code. Seeing the source code (or what’s asserted to be the source code) requires decompiling the software, which is hard to do and is often a violation of the user’s contract. This puts the responsibility to identify vulnerabilities in a software product squarely on the shoulders of the developer of that product.
[ii] Because names for individual software products vary widely based on the context in which the software is being referred to, the only reliable way to identify a software product in a vulnerability database like the NVD is to have a single machine-readable identifier. CPE is the oldest machine-readable software identifier.
Until October 2025, CPE was the only software identifier supported by the NVD. At that time, support for the PURL identifier was added to the CVE Record Format, so that CNAs now have the option of using PURL to identify the vulnerable software in a CVE record. However, PURL can currently only be used to identify open source software found in package managers. Work is now proceeding (in the PURL working group) to extend PURL to identify open source software not found in package managers, including programs written in C and C++.
However, by far the biggest “hole” in PURL coverage is commercial software, which is almost never distributed through package managers. Extending PURL to identify commercial software products isn’t a technical problem at all, but requires a) developing, with commercial developers, protocols which the developers will follow to make naming information about their products available to the public, then b) conducting education and training to get commercial developers to follow those protocols. The required protocols will almost certainly be easy to follow.
Note that, unlike CPE names, PURLs for commercial software, like PURLs for open source software projects in package managers, will not need to be created by a central authority, nor to have a central database. This is the primary reason why PURL has become by far the most widely used identifier for open source software.
An OWASP group, called the PURL Expansion Working Group, has been approved to address expansion of PURL to commercial software; the group is led by Tom Alrich and Steve Springett, OWASP Global Chairman. If you would like to learn more about this group, please email Tom at the address below.