tac
tac copied to clipboard
ossf
VDWG Issue 161: Proof of concept and training for implementation of purl in CVE Program
Technical Initiative
Vulnerability Disclosure Working Group
Lifecycle Phase
Graduated
Funding amount
$25000
Problem Statement
Most cyberattacks, successful or not, exploit software vulnerabilities. Even though software developers try to remove all vulnerabilities from their products before they ship them, most vulnerabilities are discovered after the product has been in use for some time, often many years later. CVE is by far the most widely used identifier of software vulnerabilities. New CVE numbers (for example, “CVE-2025-12345”) are assigned by a CVE Numbering Authority (CNA) and included in a CVE Record, which is submitted to CVE.org. Perhaps the most important piece of information in a CVE Record is the “affected product(s)” – the software product(s) that are affected by the vulnerability. The product is described in text in the CVE Record, but text identifications of software are inexact. Besides the textual description, the product should be identified with a machine-readable software identifier. Without such an identifier, truly automated vulnerability management is impossible. Currently, the only machine-readable software identifier permitted in CVE Records is CPE, which stands for “Common Platform Enumeration”. CPE has multiple problems (see below). However, the most serious problem currently is the fact that the National Vulnerability Database (NVD), which for more than a decade added CPE names to CVE Records, drastically cut back that activity in February 2024; since that time, the problem has become worse, not better. As a result, fewer than half of the approximately 40,000 new CVEs identified in 2024 are visible to an automated search today, because they lack a CPE name. The backlog of CVE Records without a CPE name continues to grow every month; even worse, the rate at which the backlog is growing has been increasing since late in 2024. As a result, in April 2025, only about 25% of CVE Records added to the NVD since early February 2024 include CPE names; this number seldom dropped below 100% before 2024. Because of this problem, a user searching for recently identified vulnerabilities applicable to a particular product will probably not be shown any vulnerabilities (CVEs) that apply to the product, even if the text of one or more CVE Records indicates the product is affected by the vulnerability described in the record. This happens because the lack of a CPE name in a CVE record makes those records invisible to an automated search (for example, a search using the NVD’s search bar). Even worse, the user will always receive the message, “There are 0 matching records” when this happens. This is the same message the user receives if the product they were searching for has no vulnerabilities. Thus, many (and probably most) users will be led to believe that the product they’re searching for is vulnerability-free, when in fact it could be loaded with vulnerabilities. There are other reasons why an NVD search for vulnerabilities that affect a product will receive the “There are 0 matching records” message – not because the product does not have any vulnerabilities, but because of the idiosyncrasies of the CPE identifier. These include: 1. Because CPE was designed in the early 2000s when the open source software revolution was just taking off, it doesn’t accommodate open source software well. For example, very often a vulnerability is found in just one module of a library (e.g., the log4core module in the log4j library); therefore, that is the only module that needs to be patched. However, CPE does not have a consistent means of identifying a single module of a library. Thus, when the log4shell vulnerability was discovered in 2021, many users had to patch every module in the log4j library, even though just patching log4core would have been enough. 2. Open source software is often distributed through package managers. Sometimes, a single open source product will be available in different package managers. Because there are usually variations in the product’s code between package managers, when a vulnerability is reported in the product, it is important to know in which package manager(s) the vulnerability is found. However, CPE does not have a consistent means to identify a package manager for an open source product. Thus, when CPE is used to identify vulnerable products in CVE Records, the user needs to assume that any vulnerability reported for an open source product applies to every package manager in which the product is found, even though that may not be the case. 3. “Product name” and “Vendor name” are required fields in CPE. However, software product names and software vendor names are notoriously variable, especially when it comes to open source software. Because the people who create CPE names are not constrained to use particular product or vendor names when they create a CPE name, there is a lot of variability in CPE names; in other words, the same product can be represented with multiple CPE names, each of which is valid. Because of this, a user that is searching the NVD using a product or vendor name needs to guess what name was used by the person who created the product’s CPE name. If the user guesses wrong, they will receive the unhelpful message, “There are 0 matching records.” For example, the open source project “django-anymail” has been implemented in CPE names as “django_anymail”. Searching on “django-anymail” (which is how GitHub refers to the project) yields 0 matching records. As another example, searching on “Microsoft Inc” yields two CPE names, whereas searching on “Microsoft, Inc” or “Microsoft, Inc.” yields no CPEs – even though all three spellings clearly refer to the same company. 4. Even more problematic than having varying CPE names that refer to the same product is having varying names that each have vulnerabilities reported against them. For example, there are multiple CPE names that include different spellings of “Open SSL”; all those CPE names appear as the affected product in at least one CVE Record. However, since most users stop searching after they have found one spelling that has a vulnerability reported against it, they will never learn about the vulnerabilities that apply to the other spellings. Clearly, the CPE identifier has a lot of problems. What alternative software identifiers are available? Fortunately, there is one software identifier that was almost nowhere nine years ago but has now become one of the two or three most widely used software identifiers in the world; in fact, every major open source software database utilizes this identifier. It is purl, which stands for “package URL”. Purl addresses all the problems listed above, but its most important attribute is that a purl does not need to be “created” and “assigned” to a product, like a CPE does. Instead, an open source product that is distributed through a package manager already has a globally unique purl, even though nobody has written it down yet. Today, there is general agreement in the CVE “ecosystem” that purl needs to be added to the CVE Record Format as an optional software identifier; this is especially important for anyone involved in vulnerability management for open source software. Of course, CPE will remain as an active option, since all CVE records that have a machine readable software identifier today have a CPE name – and since many CNAs and end users will continue to prefer to use CPE. The majority of purls can easily be constructed based on three pieces of information a user already has: the package manager name, the name of the product in the package manager, and optionally its version string. Thus, unlike CPE, learning the purl for a product requires no lookup to a central database; the user can always create the purl themselves, using information they already know or can easily verify by looking in the package manager. The fact that most computer-literate software users should be able to create a purl for an open source product distributed through a package manager, and that purl should always match a purl included in a CVE Record by a CNA, means there will be far fewer false positive vulnerability identifications when purl is implemented in the CVE ecosystem, than occur today when CPE is the only option for software identification.
Who does this affect?
The problems with CPE affect almost all groups that are part of the OSS community: 1. All software developers (open source and commercial), vulnerability management tool providers, vulnerability database operators and end users of software need access to dependable, readily accessible data on vulnerabilities identified in software products. However, they do not have such access today, due to the many new CVE Records that do not include machine readable identifiers for vulnerable products. If CNAs had the option of including a purl in a CVE Record, they could add that themselves, rather than wait weeks (or more) for the NVD to add a CPE name. 2. Often, a software developer delays creating a patch until they have the proper identifier for the product being patched. If the CNA is given the option of using purl to identify a vulnerable product, this will enable faster fixes for vulnerabilities. 3. The fact that today most new CVE Records do not contain CPE identifiers makes it less likely that a scanning tool will identify new CVEs in products being scanned. When CNAs can include purls to identify open source products and components in CVE Records, it will be much easier for scanner vendors to identify new vulnerabilities that affect a product being scanned. 4. As described earlier, vulnerability searches based on CPE names are likely to produce false negative results (e.g., “There are 0 matching records”). The search is likely to lead a user to believe a product is vulnerability-free, when in fact it is not. Also as described earlier, searching on purl is far less likely to produce such a result.
Have there been previous attempts to resolve the problem?
Purl is heavily used in the open source community, especially as a software identifier in vulnerability databases. However, we do not believe there have been previous attempts to introduce purl into the CVE Program. In 2022, the SBOM Forum (now the OWASP SBOM Forum) developed this white paper that advocated for purl to be introduced as an alternative software identifier in the CVE Program, as well as in the NVD, but it has never been acted on until now.
Why should it be tackled now and by this TI?
There has always been an understanding in the CVE ecosystem that CPE is a problematic identifier, mainly because of the high percentage of unsuccessful searches using CPE names; this is especially true for searches for open source products. However, as described earlier, this problem has been greatly compounded in the past year by the fact that most new CVE records do not contain a CPE identifier. Because of this, most vulnerabilities reported in the past 14 months are invisible to automated searches in the NVD, meaning those searches are close to useless. What is worse is that the person conducting the search is never informed that their search has missed anything; they are likely to believe it was successful and that the product searched for has no current vulnerabilities. In fact, that is probably the opposite of the real situation. The problem of missing CPE names is getting even worse now, since the rate at which the NVD added CPE names to new CVE Records dropped from an already low 45% at the end of 2024 to about 25% at the end of March 2025; this means that an automated search for recently identified vulnerabilities in a software product is now likely to yield only about 25% of those vulnerabilities. However, this problem has led the CVE community to become much more interested in the idea of introducing alternative software identifiers in CVE Records (but not replacing CPE). Since purl is already in wide use in open source vulnerability databases, it is the most discussed alternative. At VulnCon 2025, held the week of April 7, there were several discussions devoted to purl. Multiple leaders of CVE.org made clear that purl is coming soon – including CVE Board members Pete Allor and Chris Coffin. In fact, the CVE Quality Working Group (QWG), which is responsible for maintaining and updating the CVE Record Format, has already had multiple discussions on how they can incorporate purl into the current format. Modifying the CVE Record Format (aka “CVE Schema”) to allow purl as an alternative identifier to CPE will enable much more accurate and reliable identification of vulnerable open source products in CVE Records. However, just modifying the CVE Schema isn’t enough; the revised Schema needs to be usable throughout the CVE ecosystem, starting with the CNAs that create the CVE Records and ending with the end users that search a vulnerability database to learn where their software risks lie. To prove that use of purl in CVE Records will provide benefits such as increased accuracy, greater ease of use, quicker availability of patches and more, an end-to-end proof of concept exercise, based on the modified Schema, is needed. Not only will the concept be proven, but implementation glitches will be brought to light and fixed, rather than lead to problems and mistrust when the Schema changes are rolled out in production. Besides the Schema changes, introducing purl will require an adjustment in two other parts of the CVE ecosystem: vulnerability databases and scanning tool vendors. To participate in the PoC, a vulnerability database will need to be able to accept CVE Records that contain purl. Of course, the most well-known source of CVE Records today is the NVD. There are many other databases that are based on CVE, but currently they are almost all based on the CPE software identifier, because that is the only software identifier included in CVE Records today. It is safe to say there are no vulnerability databases today that accept CVE Records that contain purl, since currently no such records are available. The operators of databases like these will need to determine: 1. How they will integrate CVE Records containing purl with existing (and future) CVE Records that contain CPE names, and 2. What changes they will need to make to their search algorithms to accommodate both CPE- and purl-based searches.
Give an idea of what is required to make the funding initiative happen
The following tasks will be addressed in this project:
Task 1: Preparation The purpose of this task is to develop plans for an end-to-end proof of concept for use of purl in the CVE ecosystem, as well as line up stakeholders that wish to participate in the PoC. The stakeholders will fall into five groups: A. Open source communities whose software is delivered through package managers; B. CVE Numbering Authorities whose scope includes open source software; C. Vulnerability database operators; D. Vendors of vulnerability management tools, including scanners; and E. Medium- to large-sized end user organizations concerned about software vulnerabilities. We will contact organization leaders in each of the five groups. We will describe our plans and ask if they wish to participate in the PoC. Whether or not an organization chooses to participate, we will ask them about their needs and use cases regarding software identifiers in CVE records. We will compile their responses in a single document, although without attribution except for a description of the type of organization (e.g., “vulnerability management tool vendor”). This, as well as all other documents developed during the project, will be made public after the project is complete. Task 2: Identify CVE Schema changes needed for Proof of Concept The CVE Quality Working Group (QWG) and Automation Working Group (AWG) have been considering changing the CVE Record Format (“CVE Schema”) to accommodate addition of purl as an alternative software identifier to CPE (of course, CPE will continue to be used in CVE Records when that is the preference of the CNA. Note that currently, purl is only used to identify open source software distributed through package managers). Our group will work with the QWG and AWG to draft a test CVE Schema that will allow purl to be an identifier for affected product(s) in a CVE Record; this document will form the basis for the Proof of Concept (Task 3). Simply having a place in the schema to put a purl will not by itself make it possible to meet the needs of all software end users and vulnerability databases. Our group will make sure purl is usable in the revised Schema, but we will also review our Schema ideas with the other parties who have a stake in the answer to that question, who were identified in Task 1. Once the required Schema changes have been identified, we will develop a test CVE Record Format. This will form the basis for the Proof of Concept. Task 3: Proof of Concept There are six steps in the PoC, which will be executed over a span of 2-3 months. Since different PoC participants will be at different stages of the process, steps A to C will all be in progress at the same time. The entire PoC will be executed asynchronously, but the full results will be included in the documentation. A. “CVE ecosystem” stakeholders are interviewed to determine their needs for vulnerability information, including the adequacy of a test CVE Record Format developed to allow use of purl. Stakeholders include CNAs, vulnerability database operators, scanning tool vendors, and medium- to large-sized end user organizations (Chris Coffin of MITRE, co-leader of the QWG, is quite concerned about bringing end users into the CVE modification process by soliciting their opinions). B. CNAs report test “vulnerabilities” in test CVE Records. CNAs will “report” test vulnerabilities in test CVE Records that contain purls. These test records will not be submitted to the CVE.org database itself, but they may be submitted to a test version of the database; from there, they will be downloaded by the vulnerability database(s) that are participating in the PoC. If it is not possible to utilize the test version of CVE.org during the PoC, the test records will be submitted directly to the vulnerability database(s) that have agreed to participate in the PoC. C. Vulnerability databases ingest test CVE Records. Each of the vulnerability databases participating in the PoC will ingest the test CVE Records that contain purls. D. Software end users test access to CVE data using purl. They will test vulnerability database access in two ways: i. Search using a purl that was included in at least one test CVE record, then make sure that every CVE for which the purl was listed as the affected product is displayed. For example, if purl ABC was listed as the affected product for CVEs 1, 2, and 3, all three of those CVEs should appear when purl ABC is searched for. ii. Search using a purl that was not included in any test CVE record, and make sure that no CVEs are displayed. E. Scanning tool vendors ingest test CVE Records that include purl and confirm that their tools are able to use purl to identify vulnerabilities in products and components being scanned. F. To conclude the Proof of Concept, the participants will prepare a document that describes (i) needs identified by PoC participants, (ii) whether and how those needs were addressed in the PoC, and (iii) what lessons were learned from the PoC – especially regarding changes needed in the CVE Schema to accommodate use of purl identifiers in the overall CVE ecosystem.
Task 4: Purl training Purl is not well understood in the CVE community. Therefore, there needs to be general training for community members, including webinars, webinar recordings available on YouTube, and FAQ documents. There also needs to be technical training for CNAs, since they will be required to create purls to include in CVE Records.
After Task 3 is finished and any required changes to the CVE Record Format have been discussed, we will present about five webinars on purl; one or two will be introductory and the others will be technically focused (e.g., creating purls for different open source ecosystems and differences between purl and CPE). Since the webinars will be recorded and made available on YouTube, any member of the CVE community will be able to view the recordings at any time in the future.
We will also develop one or two FAQs on purl. These will be aimed at general audiences. Note that both the webinars and the FAQs will focus on use of purl in the CVE ecosystem; they will not be designed as a general purpose introduction to purl itself.
What is going to be needed to deliver this funding initiative?
The following are needed to deliver this funding initiative:
- We hope to receive from CVE Program staff suggestions regarding organizations that might be interested in joining the PoC, who fall into one or more of these six groups: a. Open source communities whose software is delivered through package managers; b. CVE Numbering Authorities whose scope includes open source software; c. Vulnerability database operators; d. Developers and vendors of OSS vulnerability management tools, including scanners; and e. End user organizations.
- We will request access to the CVE.org test database. Rather than have CNAs upload test CVE Records with purl identifiers directly to the vulnerability databases that are participating in the PoC, we would like them to upload them to CVE.org and then have the vulnerability database operators download those records to use in the PoC. Since the latter is the normal practice, it will be more realistic.
Are there tools or tech that still need to be produced to facilitate the funding initiative?
No. The only likely technical need is a change to how purl is currently implemented in the CVE v5.1.1 Record Format. It is not likely that any changes will be required to the purl spec itself.
Give a summary of the requirements that contextualize the costs of the funding initiative
Costs are primarily for three contractors, Tom Alrich, Olle Johansson and Seth Larson (Seth does not have time to participate in the project work, but he will review and comment on documents). The contractors will:
- Help gather and synthesize information from CVE community members on required changes to the CVE Schema,
- Run the Proof of Concept and document its results, and
- Develop and deliver webinars and FAQs.
See SOW for further information.
Who is responsible for doing the work of this funding initiative?
Tom Alrich and Olle Johansson
Who is accountable for doing the work of this funding initiative?
VDWG TSC and Community Chair and Contractor
If the responsible or accountable parties are no longer available, what is the backup contact or plan?
Someone from the VDWG TSC will be accountable.
What license is this funding initiative being used under?
N/A
Code of Conduct
- [x] I agree to follow the OpenSSF's Code of Conduct
List the major milestones by date and identify the overall timeline within which the technical initiative plans to accomplish their goals. Any payments for services, sponsorships, etc., will require LF Legal and Financial review.
Milestone #1: Task 1 (Preparation, including identifying and documenting needs of CVE stakeholder groups) and start of Task 2 (Work with QWG and AWG to develop test CVE Schema to use in Proof of Concept). 1 month after project start. Payment: $10,000 Milestone #2: Start Proof of Concept (Task 3). 2 months after project start. Payment: $10,000 Milestone #3: Complete Proof of Concept and start working with QWG and AWG to develop PR for changes to CVE Record Format to submit to CVE.org Board. 3 months after project start. Payment: $5,000
We estimate this project will commence as soon as possible after funding is approved and the contractors’ statement of work is accepted.
If this is a request for funding to issue a contract, then OpenSSF will issue that contract. Please provide a Statement of Work (SOW) that we may review. Any contracting action will take 4-6 weeks to issue.
Contractors' SOW: https://docs.google.com/document/d/19QRehV12iTDa5iX3NF5hG21-dXNUGI46qn7Oj2NMUuE/edit?tab=t.0
Statement of Work for Tom Alrich, Olle Johansson, and Seth Larson Introduction This Statement of Work accompanies the “Technical Initiative Funding Request: Proof of concept for implementation of purl in CVE Program”. This corresponds to Issue #161 in the Vulnerability Disclosures Working Group repo. Proposed Tasks and Deliverables Task 1: Preparation The purpose of this task is to develop plans for an end-to-end proof of concept for use of purl in the CVE ecosystem, as well as line up stakeholders that wish to participate in the PoC. The stakeholders will fall into five groups: A. Open source communities whose software is delivered through package managers; B. CVE Numbering Authorities whose scope includes open source software; C. Vulnerability database operators; D. Vendors of vulnerability management tools, including scanners; and E. Medium- to large-sized end user organizations concerned about software vulnerabilities. We will contact organization leaders in each of the five groups. We will describe our plans and ask if they wish to participate in the PoC. Whether or not an organization chooses to participate, we will ask them about their needs and use cases regarding software identifiers in CVE records. We will compile their responses in a single document, although without attribution except for a description of the type of organization (e.g., “vulnerability management tool vendor”). This, as well as all other documents developed during the project, will be made public after the project is complete. Task 2: Identify CVE Schema changes needed for Proof of Concept The CVE Quality Working Group (QWG) and Automation Working Group (AWG) have been considering changing the CVE Record Format (“CVE Schema”) to accommodate addition of purl[1] as an alternative software identifier to CPE (of course, CPE will continue to be used in CVE Records when that is the preference of the CNA. Note that currently, purl is only used to identify open source software distributed through package managers). Our group will work with the QWG and AWG to draft a test CVE Schema that will allow purl to be an identifier for affected product(s) in a CVE Record; this document will form the basis for the Proof of Concept (Task 3). Simply having a place in the schema to put a purl will not by itself make it possible to meet the needs of all software end users and vulnerability databases. Our group will make sure purl is usable in the revised Schema, but we will also review our Schema ideas with the other parties who have a stake in the answer to that question, who were identified in Task 1. Once the required Schema changes have been identified, we will develop a test CVE Record Format. This will form the basis for the Proof of Concept. Task 3: Proof of Concept There are six steps in the PoC, which will be executed over a span of 2-3 months. Since different PoC participants will be at different stages of the process, steps A to C will all be in progress at the same time. The entire PoC will be executed asynchronously, but the full results will be included in the documentation. A. “CVE ecosystem” stakeholders are interviewed to determine their needs for vulnerability information, including the adequacy of a test CVE Record Format developed to allow use of purl. Stakeholders include CNAs, vulnerability database operators, scanning tool vendors, and medium- to large-sized end user organizations. B. CNAs report test “vulnerabilities” in test CVE Records. CNAs will “report” test vulnerabilities in test CVE Records that contain purls. These test records will not be submitted to the CVE.org database itself, but they may be submitted to a test version of the database; from there, they will be downloaded by the vulnerability database(s) that are participating in the PoC. If it is not possible to utilize the test version of CVE.org during the PoC, the test records will be submitted directly to the vulnerability database(s) that have agreed to participate in the PoC. C. Vulnerability databases ingest test CVE Records. Each of the vulnerability databases participating in the PoC will ingest the test CVE Records that contain purls. D. Software end users test access to CVE data using purl. They will test vulnerability database access in two ways: i. Search using a purl that was included in at least one test CVE record, then make sure that every CVE for which the purl was listed as the affected product is displayed. For example, if purl ABC was listed as the affected product for CVEs 1, 2, and 3, all three of those CVEs should appear when purl ABC is searched for. ii. Search using a purl that was not included in any test CVE record, and make sure that no CVEs are displayed. E. Scanning tool vendors ingest test CVE Records that include purl and confirm that their tools are able to use purl to identify vulnerabilities in products and components being scanned. F. To conclude the Proof of Concept, the participants will prepare a document that describes (i) needs identified by PoC participants, (ii) whether and how those needs were addressed in the PoC, and (iii) what lessons were learned from the PoC – especially regarding changes needed in the CVE Schema to accommodate use of purl identifiers in the overall CVE ecosystem. Task 4: Purl training Purl is not well understood in the CVE community. Therefore, there needs to be general training for community members, including webinars, webinar recordings available on YouTube, and FAQ documents. There also needs to be technical training for CNAs, since they will be required to create purls to include in CVE Records. After Task 3 is finished and any required changes to the CVE Record Format have been discussed, we will present about five webinars on purl; one or two will be introductory and the others will be technically focused (e.g., creating purls for different open source ecosystems and differences between purl and CPE). Since the webinars will be recorded and made available on YouTube, any member of the CVE community will be able to view the recordings at any time in the future. We will also develop one or two FAQs on purl. These will be aimed at general audiences. Note that both the webinars and the FAQs will focus on use of purl in the CVE ecosystem; they will not be designed as a general purpose introduction to purl itself.
[1] In theory, purl has been “permitted” in the CVE Schema since the spring of 2024, when version 5.1 of the Schema came into effect. However, purl was incorporated as a versioning specification, not a software identifier. This makes it quite difficult, if not impossible, to use purl as an identifier in a CVE Record today. Project Cost This project will be delivered for a total fee of $25,000. The payment schedule is the following: Milestone #1: Task 1 (Preparation, including identifying and documenting needs of CVE stakeholder groups) and start of Task 2 (Work with QWG and AWG to develop test CVE Schema to use in Proof of Concept). 1 month after project start. Payment: $10,000 Milestone #2: Start Proof of Concept (Task 3). 2 months after project start. Payment: $10,000 Milestone #3: Complete Proof of Concept and start working with QWG and AWG to develop PR for changes to CVE Record Format to submit to CVE.org Board. 3 months after project start. Payment: $5,000 Project Timeline This project will commence as soon as possible after funding is approved and the contractor’s statement of work is accepted. The project will last about four months and will require 300 - 350 hours of work, all performed remotely. About Tom Alrich Tom Alrich is an independent consultant specializing in supply chain cybersecurity and software vulnerability management. Tom has consulted on and managed cybersecurity projects since 2001; he has worked previously for Honeywell and Deloitte. Since 2013, he has written Tom Alrich’s Blog, which addresses topics including supply chain cybersecurity and software vulnerability management. Tom formed the OWASP SBOM Forum in 2022 to address issues that are preventing widespread use of software bills of materials (SBOMs) by end user organizations; the group meets bi-weekly and includes a number of leaders of the software supply chain security industry. Since 2022, that group has focused on the software “naming problem” as perhaps the most important problem preventing widespread SBOM use. In 2022, the group produced this white paper on the question of software identification in the National Vulnerability Database (NVD). Tom lives in Evanston, Illinois and has a BA in Economics from the University of Chicago. He is the author of “An Introduction to SBOM and VEX”. About Olle Johansson Olle E Johansson is a well-known consultant based in Sweden. He is a member of the OWASP CycloneDX industry working group, and he is the project lead for the OWASP Transparency Exchange API.
Olle has over thirty years of experience of working with standardisation, communities and software development. He has run his own company, Edvina AB, since 1987.
He is also a co-founder of SBOM Europe.
About Seth Larson Seth Larson is Security Developer-in-Residence for the Python Software Foundation. He is an active member of the OSSF.
Vote created
@steiza has called for a vote on VDWG Issue 161: Proof of concept and training for implementation of purl in CVE Program (#476).
The members of the following teams have binding votes:
| Team |
|---|
| @ossf/tac |
Non-binding votes are also appreciated as a sign of support!
How to vote
You can cast your vote by reacting to this comment. The following reactions are supported:
| In favor | Against | Abstain |
|---|---|---|
| 👍 | 👎 | 👀 |
Please note that voting for multiple options is not allowed and those votes won't be counted.
The vote will be open for 14days. It will pass if at least 55% of the users with binding votes vote In favor 👍. Once it's closed, results will be published here as a new comment.
![git-vote[bot] avatar](https://avatars.githubusercontent.com/in/206179?v=4 "Published by a pub.dev verified publisher"){kind=small}
The Problem Statement and "Why should it be tackled.." sections above are quite long, and there's no link to a formatted document. If you want to see either of those sections in Word format with paragraphs, please email me at [email protected]
Vote status
So far 0.00% of the users with binding vote are in favor and 0.00% are against (passing threshold: 55%).
Summary
| In favor | Against | Abstain | Not voted |
|---|---|---|---|
| 0 | 0 | 0 | 9 |
Binding votes (0)
| User | Vote | Timestamp |
|---|---|---|
| @steiza | Pending | |
| @justaugustus | Pending | |
| @mlieberman85 | Pending | |
| @scovetta | Pending | |
| @bobcallaway | Pending | |
| @lehors | Pending | |
| @gkunz | Pending | |
| @marcelamelara | Pending | |
| @camaleon2016 | Pending |
Non-binding votes (1)
| User | Vote | Timestamp |
|---|---|---|
| Tomalrich | In favor | 2025-04-21 13:16:27.0 +00:00:00 |
I consider this worth investigating. Reading the proposal in all its detail and considering the various angles, relationships with other entities, and potential follow-up activities, this feels more like a proposal for a new SIG within the VDWG. A SIG would allow to include additional participants, and could act as a home for follow-up work items. Has this been discussed in the WG?
Thanks, Georg. That's a great suggestion! I'll be glad to volunteer to lead that, perhaps with Olle Johannson, although I know he has a lot on his plate already.
Tom
Tom Alrich LLC
312-515-8996
My book "Introduction to SBOM and VEX" is now availablehttps://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 thishttps://tomalrichblog.blogspot.com/2024/02/introduction-to-sbom-and-vex-both.html post.
From: Georg Kunz @.> Sent: Monday, April 28, 2025 5:09 PM To: ossf/tac @.> Cc: Tom Alrich @.>; Author @.> Subject: Re: [ossf/tac] VDWG Issue 161: Proof of concept and training for implementation of purl in CVE Program (Issue #476)
[https://avatars.githubusercontent.com/u/11921824?s=20&v=4]gkunz left a comment (ossf/tac#476)https://github.com/ossf/tac/issues/476#issuecomment-2836843414
I consider this worth investigating. Reading the proposal in all its detail and considering the various angles, relationships with other entities, and potential follow-up activities, this feels more like a proposal for a new SIG within the VDWG. A SIG would allow to include additional participants, and could act as a home for follow-up work items. Has this been discussed in the WG?
— Reply to this email directly, view it on GitHubhttps://github.com/ossf/tac/issues/476#issuecomment-2836843414, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AVCDY66NIHQ5XCO22RDUFXD232RJXAVCNFSM6AAAAAB3NS2QPWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDQMZWHA2DGNBRGQ. You are receiving this because you authored the thread.Message ID: @.***>
Will the funding go to 1 or all of the "consultants"? Isn't Seth Larsen an LF employee? If so, is this a conflict of interest? Why does this work require funding? Could this work be done by a SIG? Does the funding speed up the timetable? What is the net net at the end? What do we end up with?
The funding will go to the project team, but Seth has deliberately limited his role to reviewing and commenting on documents prepared by the others (Olle and me). He won't be executing the project itself.
There is currently no SIG for this. That was what Georg Kunz suggested in his comment yesterday. I think that's a good idea and I've volunteered to lead the SIG, if it ever gets formed. However, the proof of concept will require a lot of work that the SIG wouldn't be expected to do. See the SOWhttps://docs.google.com/document/d/19QRehV12iTDa5iX3NF5hG21-dXNUGI46qn7Oj2NMUuE/edit?tab=t.0 for more information.
Tom Alrich LLC
312-515-8996
My book "Introduction to SBOM and VEX" is now availablehttps://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 thishttps://tomalrichblog.blogspot.com/2024/02/introduction-to-sbom-and-vex-both.html post.
From: Jay White @.> Sent: Tuesday, April 29, 2025 7:25 AM To: ossf/tac @.> Cc: Tom Alrich @.>; Author @.> Subject: Re: [ossf/tac] VDWG Issue 161: Proof of concept and training for implementation of purl in CVE Program (Issue #476)
[https://avatars.githubusercontent.com/u/103074150?s=20&v=4]camaleon2016 left a comment (ossf/tac#476)https://github.com/ossf/tac/issues/476#issuecomment-2838450059
Will the funding go to 1 or all of the "consultants"? Isn't Seth Larsen an LF employee? If so, is this a conflict of interest? Why does this work require funding? Could this work be done by a SIG? Does the funding speed up the timetable? What is the net net at the end? What do we end up with?
— Reply to this email directly, view it on GitHubhttps://github.com/ossf/tac/issues/476#issuecomment-2838450059, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AVCDY6ZZ32BMGATQJGS6IAT235VTDAVCNFSM6AAAAAB3NS2QPWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDQMZYGQ2TAMBVHE. You are receiving this because you authored the thread.Message ID: @.***>
@SecurityCRob mentioned in today's TAC meeting that this proposal will be withdrawn and reworked. I'll leave him and others to provide more details here.
Vote cancelled
@Naomi-Wash has cancelled the vote in progress in this issue.