SBOM today: What is the state of SBOMs?
summary
Log4j prompts the push for SBOMs and the Cyber Resilience Act mandates long term product records, yet automation and tooling remain immature: many teams still get SBOMs by email while a single product can reference 2,000 upstream projects. Formats improve—SPDX (v2 ISO) and CycloneDX 1.7 → 2.0—and open tools exist (Dependency-Track scaling work, sbomdiff, sbom-audit, sbom-to-doc), but component naming, vulnerability databases and API exchange remain unsolved.
AI-written summary · about
chapters (23)
- 0:00SBOMs introduction
- 1:39Log4Shell urgency
- 3:03SBOMs as transparency tools
- 4:09SBOMs for vulnerability management
- 6:14Cyber Resilience Act requirements
- 7:00SBOM types and limitations
- 8:27Linking SBOMs to assets
- 9:27Automating SBOM in CI/CD
- 10:55SBOM adoption and tooling
- 13:04License compliance use case
- 13:49SBOM formats progress
- 14:34SBOM tooling gaps
- 15:38Vulnerability management limits
- 16:44SBOM as CI/CD tool
- 17:45SBOM collaboration standards
- 18:28CycloneDX 2.0 standards
- 19:10Package URL automation
- 20:15Dependency Track tools
- 21:22Open source SBOM tools
- 22:45Avoiding SBOM traps
- 23:08Joining SBOM communities
- 23:51European SBOM events
- 24:56Closing remarks and Q&A
related talks
27mSBOM: The Rest Of the Story
29mThe Current State of SBOMs for End Users
57mSBOMs – The Missing Link
20mSBOMs in the Real World: Practical Guidance for Managing Three Common SBOM Sce...
16mKeynote: SBOM is Coming: Why You Should Care and How You Can Help
35mSBOMs: Navigating the Evolving Landscape of Software Bill of Materials
35mBOF: SBOMs for Embedded Systems: What's Working, What's Not?
46mSBOMs Are Not Enough