Navigating the Challenges of Meeting Government SBOM Regulations in Decoupled Archite...
summary
Explains why SBOMs alone fail for cloud‑native, decoupled systems and shows concrete remediation steps: expect 30 to 50 services (conservative, often >100) each with its own SBOM, government vendors taking >100 days to remediate while attackers exploit in <10, and Log4j costing ~$9.5 trillion. Demonstrates two tools for aggregation and continuous tracking—bom control for merging SBOMs and Ortilius as an evidence store that syncs with OSV, versions SBOMs, maps deployments and drives targeted fixes.
AI-written summary · about
chapters (15)
- 0:00SBOM challenges in decoupled architectures
- 2:27Why SBOMs matter for vulnerability response
- 5:20Government SBOM requirements
- 8:51Managing SBOMs in microservices
- 11:58Tools for aggregating SBOMs
- 14:04Ortillius as evidence store
- 20:29AI remediation for SBOM vulnerabilities
- 23:58Ortillius goals and community
- 26:05Q&A
- 27:11Q&A: GitLab runners and MCP
- 27:56Q&A: SaaS vs standalone
- 28:39Q&A: Pinning fixes in files
- 29:26Q&A: Ortillius vs Renovate/Dependabot
- 30:11Q&A: Post-deployment tracking
- 31:15Q&A: Why vulnerabilities persist
related talks
26mSBOM today: What is the state of SBOMs?
38mThe State of SBOMs
53mIs SBOM for the Cloud Even a Thing?
50mRealities of SBOM: What Is Under the Hood of SBOM?
29mUnlocking the Power of SBOMs: A Deep Dive into Risk Management and Cybersecurity Posture
41mAll About That BoM, ‘bout That BoM
46mSBOMs Are Not Enough
22mBuilding a Robust SBOM Solution with Backstage.io