Now that PURL is in the CVE Schema, how do we make it work in practice?

[Tomalrich]

The PURL software identifier has now been incorporated into the CVE Record Format. This means that CNAs now have the option of using a PURL to identify a vulnerable open source software product in a new CVE record, in place of or in conjunction with a CPE identifier. However, this is just the first step required for PURL to be widely used – or even used at all – in CVE records. The following three tasks need to be executed, in order for PURL to be widely used in CVE records.

Task 1: Enlisting vulnerability databases to support PURL in CVE records
The first task, which is required for there to be any use of PURL in CVE records at all, is to make sure there is at least one vulnerability database in which someone can search with a PURL and find CVE records that reference that PURL. It’s axiomatic that there is currently no such database, since no CVE records today include PURL (unless they’re test records created in the last month or two).

However, there is one database today that allows PURL searches for CVE information. Sonatype’s OSS Index has supported PURL searches for years, but that is based on Sonatype’s own identification of vulnerabilities in OSS, not on CVE records that include PURLs. I believe they do this through scanning code in GitHub as well as by other means. This approach has been very successful. In fact, Dependency Track alone is used over 25 million times per day to look up an open source dependency found in an SBOM in OSS Index.

OSS Index will probably be the first vulnerability database to make it possible to search for CVE records that include PURL. Moreover, it will certainly remain the only database that lists legacy CVE numbers when a user searches using a PURL.
However, since the National Vulnerability Database (NVD) is considered by most users worldwide to be the primary source of CVE information, it is important for the NVD (or at least one or more of its partners like VulnCheck, Vulners, VulnDB, and VulDB) to support PURL searches as well as searches for CPE names.

A similar effort is required for vulnerability scanning tool vendors. They also need to support CVE records that include PURLs as well as CPE names, so they can provide complete scan results.

Task 2: Proof of concept
A second task is required before there can be any substantial use of CVE records that contain PURLs. That is an end-to-end proof of concept that demonstrates that including PURLs in CVE records can work in practice. The steps in the PoC will include (but are not limited to):

1. A CNA creates a new CVE record (CVE-2026-12345) reporting a vulnerability in the ABC Browser. The product is identified using a PURL.
2. The record appears in CVE.org.
3. The record is downloaded by a vulnerability database and ingested into the database.
4. An end user searches the database using that PURL and learns that a product they use, ABC Browser, is affected by CVE-2026-12345.

A variant of this PoC is:

1. A CNA creates a new CVE record (CVE-2026-12345) reporting a vulnerability in the ABC Browser. The product is identified using a PURL.
2. The record appears in CVE.org.
3. The record is downloaded by a scanning tool vendor and ingested into their vulnerability database.
4. When one of those tools scans Bob’s Browser, the tool identifies CVE-2026-12345 in that product.

Task 3: PURL and CVE training
A third task, which needs to be performed both now and in the future, is training on PURL for software suppliers (including open source projects), CNAs, vulnerability database operators, end users, and other members of the CVE ecosystem.
Also, since many people in the open source community are familiar with PURL but not with the CVE program, “CVE 101” training is important as well.

Task 4 (extra credit): PURLs for commercial software
There is another task that would be highly desirable to undertake, even though it is not necessary for purl to be successfully used in CVE records in the near future. Currently, PURL primarily supports software available in package managers, which is almost entirely open source. However, the commercial software world needs PURL as much as the open source world (where PURL is widely used today) does.

PURL has huge advantages over CPE for open source software distributed in package managers. When it is able to identify commercial (aka “proprietary” or “closed source”) software, those advantages will be even greater. One of the greatest advantages is that the Vendor field in PURL is optional, not mandatory. Since most open source software doesn’t have a true vendor, that isn’t a big issue.

However, in commercial software there can be hundreds or even thousands of different answers to the question of who the vendor is, since even the employees of a company like Microsoft give very different answers to the question of who they work for.

CPE names are created by NIST/NVD contractors or employees, but they’re added to a CVE record originally developed by the CVE Numbering Authority (CNA), which is often the vendor of the software. Presumably, the vendor name that the vendor puts in the text of the CVE record is their authoritative name, but often the NVD person who creates the CPE uses a different name for the vendor (overriding the name inserted by the CNA), because that name has been used in other CPEs.

How do these questions get resolved? They don’t. There’s simply no way to determine what is the definitive name for the vendor, any more than there is a way to determine the definitive name for the software product itself. The bottom line is that, when someone is trying to find the CPE name for a product they use, there is no way they can know for sure what names are in the vendor and product fields; they must simply take a guess.

Since the NVD displays a message reading “There are 0 matching records” in many different cases, a user does not know whether that means the product has zero vulnerabilities, or whether it means the product has lots of vulnerabilities, but it’s listed under a different CPE name than the one they searched on.

However, despite the fact that CPE is an inadequate identifier, it is the only one available for commercial software products. Since the great majority of medium-to-large organizations worldwide mostly utilize commercial software to run their operations, the fact that they must rely on CPEs to search in vulnerability databases for software products they use adds another layer of uncertainty to their already uncertain software supply chain vulnerability management efforts.

The primary reason why PURL has been so successful as an identifier for open source software is that it currently is limited to OSS distributed through package managers, which inherently have a “controlled namespace”. In other words, the operator of the package manager makes sure that no two products have the same name and version string, and that each product has only one name and version string.

This means that the combination of package manager name (which is encoded in the PURL Type field), product name and version string (the only three fields that are mandatory for PURL. Note that version string is optional if the product isn’t versioned) is guaranteed to be globally unique.

Therefore, the PURL that the CNA creates to identify the product when they report a vulnerability in a new CVE record is the same PURL that a user will create when they look up that product in a vulnerability database. This is because the user will always be able to verify a) the package manager from which they downloaded the product, b) the name of the product in that package manager, and c) the version string of the product in that package manager.

However, since commercial software is almost never downloaded from a package manager, how can there be a controlled namespace so that PURL can work? Steve Springett, leader of the OWASP Dependency Track and CycloneDX projects and an early collaborator with Philippe Ombredanne on PURL, has proposed a new PURL Type called scid.

In Steve’s proposal, whenever a supplier releases a new software product or a new version of an existing product, they will post the values for all the PURL fields on their website, along with the product/version’s PURL; they will also distribute this information through the upcoming Transparency Exchange API (TEA).

When the supplier reports a vulnerability in the product, they will use that PURL to identify the product in the CVE record. And when a user tool is searching a vulnerability database for that product, the tool will be able to find the PURL using TEA. Of course, since the supplier is the source of both PURLs, they should always match, and a search for vulnerabilities for a commercial product should always find any that have been reported using PURL.

The fourth task includes the following sub-tasks:

1. Develop a pull request for adding the scid Type to PURL.
2. Once the PR is accepted and the change has been made, test use of the scid Type to identify multiple commercial software products.
3. Develop protocols for distribution of purl fields, and the purl itself, for each supported version of a commercial supplier’s products. These protocols can include making the information available at a known URL on the supplier’s website, operation of a Transparency Exchange API server, etc.
4. Test operation of these protocols in a tabletop exercise.
5. Educate the CVE community, especially commercial suppliers and CNAs working with commercial suppliers, on both PURL and use of the PURL scid Type.

What’s to be done?
Of course, the first three tasks need to be accomplished as soon as possible, since they are necessary for PURL to be widely used, or even used at all, to identify open source software in CVE records. Once those three tasks have been achieved, work on the fourth task can begin, although, since the fourth task doesn’t depend on the first three tasks being already accomplished, it could proceed simultaneously with them.

Of course, someone needs to organize and manage execution of all four tasks (although the fourth task could be executed under different leadership than the first three tasks). Since I am at the limit of work that I can perform on a volunteer basis, I am hoping that someone can undertake these tasks. I would be glad to discuss this with anybody interested.