The Evolution of SBOMs in AlmaLinux
summary
AlmaLinux has produced per-package SBOM data for over a year by storing build metadata in an immutable build database and using a client SBOM generator that originally emitted CycloneDX and now supports SPDX. Adding SPDX reveals gaps versus NTIA Minimum Elements, so investigation targets build-system and database schema changes to capture CPEs, purl, build tools (mock), source commit hashes and RPM epoch/version/release. Cyclic RPM dependencies make per-package SBOM linking impractical, so the team prototypes a deployed SBOM — one SBOM for a whole installation to record exact dependency versions; proof-of-concept is in progress.
AI-written summary · about
chapters (13)
- 0:00Introduction
- 1:05SBOMs in AlmaLinux overview
- 2:09Regulations driving SBOMs
- 3:56Generating SBOMs in AlmaLinux
- 6:23Current SBOM contents
- 8:54Missing SBOM data
- 11:23SBOM generation challenges
- 15:56Deployment SBOMs solution
- 18:27Build SBOM format demo
- 22:08Engaging with SBOM development
- 23:24Q&A: Dependency resolution
- 27:41Q&A: Beyond AlmaLinux
- 28:50Q&A: SBOM authorship
related talks
27mSBOM: The Rest Of the Story
43mUsing SBOMs for Linux Foundation Projects
34mSo, SBOMs Matter…Now What?
37mSBOM Implementation Reality: From Crawl to Walk - SPDX Lite Pro...
01h 26mPractical Software Bill of Materials: From Generation to Distribution Workshop
32mComposing the Ultimate SBOM
38mEnhancing SBOM Generation: Filling the Gaps To Make Actionable SBO...
26mSBOM today: What is the state of SBOMs?