C0c0n Shiny Sbom

This presentation at C0c0n 2024 builds on the SBoM narrative, asking the practical question: now that organizations have generated their “shiny” Software Bill of Materials, what should they actually do with it? Anant Shrivastava maps the SBoM journey from generation through distribution, verification, and consumption, introduces the different stakeholder roles (library authors, producers, consumers, end users), and showcases a growing ecosystem of consolidated SBoM tooling — culminating in a live demonstration of SBoM Play, an open-source tool for extracting actionable intelligence from SBoMs.

Key Topics Covered

The SBoM Journey Stages:

• Generation: Creating the SBoM using tools like cdxgen, SPDX Generator, or GitHub dependency graph exports
• Distribution: Sharing SBoMs with downstream consumers and partners
• Verification: Validating SBoM accuracy and quality
• Consumption: Actually using SBoM data to drive decisions — the least mature stage and the focus of this talk

Catalyzing Events and Regulatory Landscape:

• Key incidents (SolarWinds, CodeCov, Colonial Pipeline) led to the US Executive Order, NIST SSDF Framework, and Google’s SLSA
• India’s CERT-In issued SBoM guidelines in 2024, expanding the mandate beyond US-centric requirements
• Three competing standards persist: SPDX (ISO, GitHub default), CycloneDX (OWASP, now also ISO), and SWID

SBoM Stakeholder Roles:

• Library authors produce base functionality SBoMs
• Producers (product companies) both consume upstream SBoMs and produce their own
• End users/consumers can only leverage the product — limited to upgrade or hold decisions

Industry Skepticism and Systemic Challenges:

• Organizations question why they should disclose composition, restrict sharing to NDA-covered entities, or dismiss SBoM because they don’t sell to the US
• The software industry is largely fixing problems it created: faster release cycles reduce dependency upgrade incentives, OSS maintainers are under-supported, and automated vulnerability notifications create alert fatigue

Consolidated SBoM Tooling Ecosystem:

• Format-agnostic tools: bomctl for cross-format SBoM manipulation
• Policy-driven security: Vet by SafeDep for dependency vetting
• Quality assessment: sbomqs by Interlynk and sbom-status by ServiceNow
• SBoM merging: sbomasm by Interlynk for combining multiple SBoMs
• End-of-life detection: xeol for identifying EOL components
• Scoring: eBay’s sbom-scorecard for SBoM quality rating

SBoM Usage Beyond Security Teams:

• For developers: manage technical debt, reduce dependency scatter, consolidate library usage, simplify package selection for new projects
• For M&A: assess acquisition costs via outdated/EOL software indicators, evaluate tech stack alignment and team cohesion
• For compliance: track licensing at component level, identify GPL and other restriction risks
• For risk management: quantify vendor software risk, evaluate SSO token exposure, make environment-aware risk decisions

Key Analytical Concepts:

• EOL code detection across the dependency tree
• Package drift identification between environments or versions
• License violation scanning at transitive dependency levels
• OpenSSF Scorecard integration for open-source health assessment

SBoM Play Tool:

• Open-source tool at github.com/cyfinoid/sbomplay for practical SBoM exploration
• Downloads organization-level SBoMs, stores in SQLite, and generates reports
• Demonstrates that working with SBoMs is technically straightforward — the hard part is quantifying the monetary value

Actionable Takeaways

1. Move beyond SBoM generation to focus on the consumption and analysis stage — generating SBoMs without a usage strategy delivers minimal value.
2. Adopt format-agnostic tooling like bomctl to avoid vendor lock-in to a single SBoM standard and enable cross-format workflows.
3. Implement SBoM quality checks using tools like sbomqs or sbom-scorecard before relying on SBoM data for security decisions.
4. Use SBoM Play or similar consolidated analysis tools to extract business intelligence from SBoMs — including dependency drift, EOL components, and license violations.
5. Quantify SBoM value in monetary terms by calculating the cost impact of library changes, package upgrades, code rewrites, and distribution — this is the key to organizational buy-in.
6. Produce outputs in business-friendly formats (PDF, HTML, Excel) rather than CLI-only pipelines to make SBoM insights accessible to non-technical stakeholders.