SBOM Quality: We Need More Than a Simple “SBOM Button” for Compliance
summary
Explains why a single “SBOM button” is insufficient, demos practical checks and tools that improve SBOM quality such as ScanCode and scanCode.io, SPDX and CycloneDX interoperability, package URL identifiers, and back-to-source binary matching; shows reproducible builds, SLSA attestations and ecosystem fixes like cargo auditable build to embed provenance; describes approximate snippet matching for AI‑generated code and a collaboration with Hugging Face; reveals thousands of Maven artifacts still shipping vulnerable log4j binaries and concrete scanning/outreach workflows that found them.
AI-written summary · about
chapters (16)
- 0:00SBOM quality and compliance
- 1:47About AboutCode
- 3:34What is SBOM and why it matters
- 6:29Package URL and standards
- 8:16Global SBOM regulations
- 11:05Problem with SBOM button
- 12:12Package manifest challenges
- 15:06SBOM types and limits
- 18:14Why build phase is ideal for generating SBOMs
- 21:27Traceability in builds
- 23:33Beyond package manifests
- 25:18AI and copied code in SBOMs
- 28:07Improving SBOM at source
- 30:33AboutCode licensing fixes
- 31:57AboutCode tools and community
- 33:22Q&A
related talks
46mSBOMs Are Not Enough
27mSBOM: The Rest Of the Story
45mSmarter Than Your Average SBOM!
26mSBOM X-Ray Superpowers: Making Better SBOMs, Using SBOMs
23mSBOM adopatability in open source software scanning
45mSmarter Than Your Average SBOM!
41mYour SBOM Is Lying To You – Let’s Make It Honest
37mSBOMs Aren't Enough. Secure Your Software Supply Chain End-To-End
