Discussions regarding purl implementation in the CVE Program

[Tomalrich]

trafficstars

There is growing recognition in the CVE community that there needs to be an alternative software identifier to CPE available for use in CVE Records. Along with CPE, one of the most widely used software identifiers is purl (which stands for “Product URL”). Coming from nowhere ten years ago, it is now heavily used to identify open source software packages.

In December, the leaders of the CVE Quality Working Group (QWG) requested a “proposal” to implement use of purl as a second identifier in the CVE ecosystem, along with CPE. The OSSF VDWG has prepared this draft Implementation plan.

However, there are three issues that need to be addressed before that plan can be set in motion:

1. To move ahead on implementing use of purl in the CVE Program, there needs to be evidence of good support for this move among the CNAs and other members of the CVE community.
2. Even though purl became “legal” in CVE Records when CVE Record Format v5.1 came into effect last May, CNAs are not using that capability today. This is partly because of how purl was included in the CVE Record Format, but also because the CNAs clearly aren’t comfortable with purl yet. This is most likely because they have so far received no training on purl or how to use it.

3. Some small changes to how purl is included in the current CVE v5.1.1 format may be required.
   

To address these issues, the VDWG has developed a project plan titled “Discussions regarding purl implementation in the CVE Program”. That plan includes:

1. Training on purl and its proposed implementation in CVE. We will deliver a webinar aimed mostly at CNAs, as well as a white paper on this topic. The goal will be to provide enough training to the CNAs that we will not have to spend much time on training during the purl workshop to be conducted during VulnCon 2025.

2. Conduct Q&A sessions with CNAs, in web meetings and emails. The goal of these will be to enumerate outstanding questions that CNAs have regarding purl and how it will be helpful to them. 
   

3. Discussions with vulnerability database operators. There are three vulnerability databases, one "for pay" and two free, that can most likely ingest CVE Records that include purls and make the purls searchable in the database. We will ask all of them whether they wish to participate in the Proof of Concept that will be the main feature of the Implementing project, as well as what they will provide with their database lookup service.
4. Discussions with software developers, end users and vulnerability management service providers. The goal will be to learn what each of these groups needs regarding purl.
5. “Purl workshop” at VulnCon. This workshop (still being scheduled) will hopefully bring together members of all the above groups. The goal of the workshop will be to answer unanswered questions, as well as address concerns that any participants may have about purl or how it can be implemented in the CPE Program.

6. Prepare project documentation. The results of the "purl workshop" will be summarized and presented in a new webinar, with video available on YouTube.
   

[TheFoxAtWork]

Mind i have not been active in the VDWG (and am very likely missing a substantial portion of history, backstory, reasoning etc.), and this only came across my radar due to a mailing list exchange but i have several concerns specific to the implementation portions of this proposal, in large part because it appears the impetus of this work is solely to the perceived benefit of commercial entities (for which there lacks supporting evidence) and NOT for the open source projects or their security for which this foundation exists (as a benefit of its members).

That does not mean to say this is a bad idea. Rather that the OpenSSF is likely the inappropriate entity to execute a majority of the proposal's implementation and leaves me to question why it is being presented to OpenSSF in the first place and not through the existing bodies and groups under which appropriate identification of software for vulnerability management is their remit? Has it been presented and rejected by those groups? Why? Sure, OpenSSF is a key stakeholder in those discussions to influence and drive support for open source project identification, advocating for the inclusion, discovery, and accuracy in results for their identifying mechanisms (pURL) but last i reviewed the charter the OpenSSF does not exist to inspire and enable ~~the community~~ industry to secure the ~~open source~~ commercial software ~~we all depend on~~ available for purchase.

I've provided specific comments in the relevant areas of the implementation document, foregoing substantial comments for Phase II as i strongly believe it is beyond the scope of this foundation and would not be a productive use of time for myself or the author(s) to adjudicate.

[Tomalrich]

Thanks for your email, Emily, and for all the perceptive comments you left on the document. I've just responded to (almost) every one of them! To summarize my responses: The project that's on the table now (I created an Issue for it in the VDWG repo yesterday) is the Preparation proposal. We won't even start seriously discussing the Implementation proposal until we've gotten lots of feedback from the CNAs and other members of the CVE world, as part of the Preparation project. Phase I of the Implementation project is all about OSS, nothing commercial (although there are many commercial organizations that are quite familiar with purl from their work with SBOMs). Phase II is all about commercial software, but we probably won't even start seriously discussing Phase II until we're well down the path of Phase I. Phase I stands completely on its own. If we never do phase II at all, Phase I will still be well worth doing. So I hope you'll participate (or at least support) Phase I when the time comes. The proposal regarding SWID tags in Phase II is there because we want purl to be a complete alternative to CPE (we're not advocating elimination of CPE, of course! Purl will be just a second identifier). Currently, purl just identifies OSS (and not all OSS, but mainly OSS in package managers), while CPE identifies OSS and commercial software.

[TheFoxAtWork]

@Tomalrich i've added suggestions in a few areas and provided additional recommendations based on your responses, i appreciate you taking the time to illuminate more of the background so that is can be appropriately incorporated into improving the overall proposal.

[Tomalrich]

Today, I revised the original Issue to reflect three important changes I've made:

1. I made it clearer in the "Discussions regarding purl implementation in the CVE Program" plan that the first goal of that project is to determine whether there is good support among the CNAs for implemening purl as an optional identifier in CVE Records. If there isn't, we will never seek approval for the Implementation project.
2. I removed Phase II (regarding use of the purl SWID type to identify commercial software products) from the original implementation plan and made it a separate project called "DRAFT: Expanding purl to identify commercial software".
3. I also made it clearer that the implementation plan will address purl for OSS - i.e., the current capabilities of purl. Once the implementation project is finished (mid-2026?), we will make a decision whether or not to seek approval for the "Expanding" project. My guess is that project will be moot by that time. Oracle is going to kick off a proof of concept of purl/SWID in February 2025, so there may not be any need to execute that project, even setting aside the legitimate question whether the OSSF should do a project that will benefit private software developers more than OSS projects.