We need PURLs for commercial software products #22
Description
"As a role performing task, I struggle with problem because reason."
As a consultant helping organizations identify vulnerabilities in software products they use, I struggle with the problem that it is hard to learn about vulnerabilities (CVEs) found in commercial products, due to the unreliability of the CPE software identifier used by the National Vulnerability Database (NVD)."
CWG Issue 20 describes serious problems with the CPE software identifier, which until recently was the only identifier supported by the NVD. This 2022 white paper by the SBOM Forum (now the OWASP SBOM Forum) provided more detail on these problems and suggested that use of the PURL identifier (then usually written as "purl") in the CVE program and the NVD would fix a lot of them. PURL is by far the most widely used identifier for open source software distributed through package managers. Tens of millions of times every day, a PURL is used to search for vulnerabilities in open source vulnerability databases like GitHub Security Advisories, OSV, and OSS Index.
In the fall of 2025, PURL was added to the CVE Record Format (also called the "CVE schema") as a second software identifier, meaning that a CNA may use PURL instead of (or along with) a CPE name to identify a vulnerable product in a new CVE record. However, since PURL was added to the CVE schema, only a few hundred new CVE records containing PURL have been created.
There are several important reasons for this (including the lack of training on PURL for CNAs, at least so far). However, the most important reason is that today PURL primarily supports open source software found in package managers, but not commercial software.
PURL currently focuses on software in package managers because a package manage provides a "controlled namespace", meaning the operator of the package manager ensures that no two products (packages) have the same name. The only three required fields in a PURL are the name of the package manager (called the "type" in PURL), the name of the product in that package manager and the version string of the product.
Because of the controlled namespace, the combination of these three pieces of information is guaranteed to be globally unique. For example, even if a package named "Open SSL version 3.6" is available in multiple package managers, since the names of the package managers are always different, the PURL for any one of those packages will always be globally unique. Even more importantly, a user can verify the PURL by checking the package's name and version string in the package manager. There is no need for a centralized registry of PURLs, which would be hugely expensive to maintain and seldom works well in practice (viz. the "CPE Dictionary" maintained by NIST - which isn't a dictionary at all, but merely an alphabetical list of existing CPE names).
Commercial software is almost never distributed through package managers. Therefore, if PURL is ever to support commercial software, a controlled namespace must be provided through some other mechanism. Steve Springett has proposed a new PURL type called SCID. This will enable commercial software to have PURL identifiers. It will also enable open source software not found in package managers, such as C/C++ programs and standalone open source projects like the Linux kernel, to have PURLs.
The OWASP SBOM Forum is putting together a project to discuss how to extend PURL to cover commercial software and if possible non-packaged open source software; the group will also take steps (like training and tooling) necessary to enable this extension to be successful. If you would like to participate in this project, please email Tom Alrich at tom@tomalrich.com.