Challenges in Open Source Software Identification
summary
Ecosystem fragmentation causes concrete failures: purl <10 CVE records despite wide OSV and SCA support (SIFT, Guac), while CPE applicability is used by Microsoft and MITRE and suffers from many duplicate, inconsistent CPEs in the NIST dictionary. Red Hat namespaces purls for 200+ products and publishes guidelines so Red Hat namespaces purls to map components to product RPMs; SBOMs carry provenance between upstream source, package index and downstream distro, but conversion tooling and stricter CVE data validation remain missing.
AI-written summary · about
chapters (12)
- 0:00Open source software ID
- 1:06What software identity means
- 4:18CPE as software ID
- 5:48Pearl for artifacts
- 10:08Downsides of Pearl
- 12:58Version ranges in Pearl
- 15:25CPE limitations in practice
- 21:07Software ID in CVEs
- 27:17OSV database approach
- 29:47Red Hat’s ID strategy
- 31:35Key ID challenges
- 37:53Q&A on standards
related talks
18mThe Current State of Open Source Security Compliance Tooling Is … Well, Sad.
47mThe Open Source Paradox: Unpacking Risk, Equity, and Acceptance
32mIs the Internet on Fire? Strategies for Mitigating Open Source...
37mGoverning Global Vulnerabilities: Standards for Open Source Resilience
26mEffective Software Supply Chain Monitoring
41mScalable Management of Vulnerabilities in Open Source
25mTrusting Your Open-Source Software Supplier
41mThe Year in Open Source Security