Assisting the CVE Program in adding purl as a software identifier

[Tomalrich]

There is growing recognition in the “CVE ecosystem” that there needs to be an alternative software identifier to CPE available for use in CVE Records (although CPE won’t be replaced). Along with CPE, the most widely used software identifier is purl (which stands for “Package URL”). Coming from nowhere ten years ago, it is now by far the most widely used identifier for OSS.

In December, the leaders of the CVE Quality Working Group (QWG) requested a “proposal” (i.e., a plan) 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] (https://docs.google.com/document/d/1YY1fkUOpaOilA9hg1tUdVTgNeJ-1PPF0cAKO1K_WKkI/edit?tab=t.0).

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

1. 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. The CNAs clearly aren’t comfortable with purl yet.
2. Even if CNAs were including purls in CVE Records today, no existing vulnerability database could make use of those records.

To address these two issues, the VDWG has developed a Preparation plan, which we wish to start executing immediately. That plan includes:
a) Holding discussions with CVE “stakeholders”, including CNAs, software suppliers, scanning tool vendors, vulnerability database providers, and large and small end users. We will: i) answer questions about purl and how it will be implemented, ii) discuss objections or obstacles they may point out, and iii) gather their suggestions for improving the Implementation plan. We hope to hold some of these discussions at VulnCon.
b) Discussing with vulnerability database operators (including but not limited to the NVD), and with potential operators, whether and how they can utilize CVE Records that contain purls. This will allow their users to locate CVE Records that reference a product by searching using that product’s purl.

This project will be executed in close coordination with the CVE QWG, SPWG and Board, as well as with the purl project.

[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: 1. The project that's on the table now (I created an Issue for it in the VDWG repo yesterday) is the Preparation<https://docs.google.com/document/d/1VfxrTqGBHifFNRIw-tWpx-GeUcdcqYvVdU4dJz-veN4/edit?tab=t.0#heading=h.pmyenulbunvu> 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. 2. 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). 3. 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. 4. 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. Thanks again for your comments! I hope you'll keep adding them. Tom Tom Alrich LLC 312-515-8996 My book "Introduction to SBOM and VEX" is now available<https://www.amazon.com/s?k=introduction+to+sbom+and+vex&crid=2IDUG1OC1P8JO&sprefix=introduction+to+sbom%2Caps%2C220&ref=nb_sb_ss_ts-doa-p_2_20>! For context, see this<https://tomalrichblog.blogspot.com/2024/02/introduction-to-sbom-and-vex-both.html> post.

…

________________________________ From: Emily Fox ***@***.***> Sent: Thursday, January 23, 2025 2:14 PM To: ossf/wg-vulnerability-disclosures ***@***.***> Cc: Tom Alrich ***@***.***>; Author ***@***.***> Subject: Re: [ossf/wg-vulnerability-disclosures] Assisting the CVE Program in adding purl as a software identifier (Issue #158) 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. — Reply to this email directly, view it on GitHub<#158 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AVCDY62ES7DFFZZCHYQZGNT2MFETRAVCNFSM6AAAAABVVG6AKSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMMJQHEZDOOBTGE>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[Tomalrich]

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 comment, 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.

t

r

[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]

Thanks, Emily. I'll go through your new comments over the weekend and reply to them. I also have decided to break out Phases I and II of the Implementing and Expanding project<https://docs.google.com/document/d/1YY1fkUOpaOilA9hg1tUdVTgNeJ-1PPF0cAKO1K_WKkI/edit?tab=t.0#heading=h.g80rl9cimdbr> into two separate projects, which will be approved separately. As we discussed, Phase I deals with purl as it now stands, which is focused almost entirely on open source. This will benefit both the open source and proprietary software communities, since at least 90% of software components are OSS and therefore usually can be identified using purl. Phase II expands purl (through revising one of the 1,000 or so purl "types", not through changing the core purl specification) to be able to identify proprietary software. It will primarily benefit providers (and users) of proprietary software, although all software users and developers will benefit from purl being strengthened in this way. As I mentioned in my previous comments to you, it will be at least a year before we can get to Phase II as an OSSF project. There's a possibility that a separate organization might execute that project before then, since it doesn't need to wait for Phase I to be finished (in fact, it would be ideal if they were both finished at the same time). Thanks so much for your comments! As you can see, the project is benefiting a lot from them. [https://lh7-us.googleusercontent.com/docs/AHkbwyKzV-4vQZJ_7wDp_SzKqPXwRBURedBnqyyy1cqd_ZaUTfzNsg-Co1lt2WzbfTTVMfJnAjAzD4eNGE7SQOuhhPvev2r4ekLitnZ6EwaLaTr-1KXGdhU=w1200-h630-p]<https://docs.google.com/document/d/1YY1fkUOpaOilA9hg1tUdVTgNeJ-1PPF0cAKO1K_WKkI/edit?tab=t.0#heading=h.g80rl9cimdbr> DRAFT: Implementing and expanding purl in the CVE ecosystem<https://docs.google.com/document/d/1YY1fkUOpaOilA9hg1tUdVTgNeJ-1PPF0cAKO1K_WKkI/edit?tab=t.0#heading=h.g80rl9cimdbr> Note: Before changing any text in this document, please make sure you are in Suggesting mode. Introduction Software security requires that all public and private sector organizations be able to learn about vulnerabilities that apply to the software products they utilize every day. This is beca... docs.google.com Tom Alrich LLC 312-515-8996 My book "Introduction to SBOM and VEX" is now available<https://www.amazon.com/s?k=introduction+to+sbom+and+vex&crid=2IDUG1OC1P8JO&sprefix=introduction+to+sbom%2Caps%2C220&ref=nb_sb_ss_ts-doa-p_2_20>! For context, see this<https://tomalrichblog.blogspot.com/2024/02/introduction-to-sbom-and-vex-both.html> post.

…

________________________________ From: Emily Fox ***@***.***> Sent: Friday, January 24, 2025 1:53 PM To: ossf/wg-vulnerability-disclosures ***@***.***> Cc: Tom Alrich ***@***.***>; Mention ***@***.***> Subject: Re: [ossf/wg-vulnerability-disclosures] Assisting the CVE Program in adding purl as a software identifier (Issue #158) @Tomalrich<https://github.com/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. — Reply to this email directly, view it on GitHub<#158 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AVCDY657AJDQSTIRSWSYC232MKK47AVCNFSM6AAAAABVVG6AKSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMMJTGI3TKMJSHE>. You are receiving this because you were mentioned.Message ID: ***@***.***>