We are reaching a scenario where SBoM generation, verification and distribution is being actively looked at. the need of the hour is to look at SBoM consumption and to look beyond security what else SBoM can be used for.
AI Generated Summary
AI Generated Content Disclaimer
Note: This summary is AI-generated and may contain inaccuracies, errors, or omissions. If you spot any issues, please contact the site owner for corrections. Errors or omissions are unintended.
This presentation at C0c0n 2024 moves past the hype of SBoM creation to address the harder question: now that organizations can generate Software Bills of Materials, what should they actually do with them? Anant Shrivastava maps the SBoM journey from generation through distribution, verification, and consumption, introduces practical tooling for SBoM quality checking, merging, and policy enforcement, and makes the case that SBoM’s true value lies in cross-functional use across development, M&A, compliance, and risk management — not just security.
Key Topics Covered
SBoM Fundamentals and Context:
An SBoM is an itemized inventory of third-party components in software, including name, version, checksum, license, and dependency data
Key supply chain incidents (SolarWinds, CodeCov, Colonial Pipeline) drove regulatory action: US Executive Order, NIST SSDF Framework, Google SLSA, and 2024 CERT-In guidelines in India
Competing standards: SPDX (ISO standard, GitHub default), CycloneDX (OWASP, now also ISO), and SWID
The SBoM Journey — Four Stages:
Generation: creating SBoMs using tools like cdxgen, SPDX tools, or GitHub’s dependency graph and API export
Distribution: sharing SBoMs with stakeholders (NDA-protected sharing, vendor requirements)
Verification: validating SBoM quality and accuracy
Consumption: using SBoMs to drive decisions — the stage where most organizations stall
SBoM Users and Their Roles:
Library Authors: produce SBoMs for base functionality
Product Producers: consume upstream SBoMs and produce their own — the critical middle layer
End Users: can only leverage the product, limited to upgrade-or-hold decisions
Industry Skepticism:
Resistance to disclosing composition publicly
SBoMs seen as a US-market compliance checkbox
Debate over whether time is better spent fixing bugs than generating SBoMs
The industry has never maintained proper software inventory, leaving organizations unsure how to use one
Identifying unauthorized or incorrect software use
Understanding blast radius of core component vulnerabilities
VDR, VEX, and expanding xBoM variants (SaaSBOM, HBOM, ML-BOM, CBOM, MBOM, OBOM) for more granular security data
Attestations for establishing trust
Consolidated SBoM Tooling Ecosystem:
Format-agnostic tools: bomctl for cross-format SBoM management
Policy-driven security: Vet by SafeDep for automated policy enforcement
Quality checking: sbomqs by Interlynk for SBoM quality scoring, sbom-status by ServiceNow
Merging: sbomasm by Interlynk for combining multiple SBoMs
End-of-life detection: xeol for flagging EOL components
Scoring: eBay’s sbom-scorecard for SBoM evaluation
Key Analytical Concepts:
EOL (End-of-Life) code detection across dependencies
Drift in packages — tracking unexpected changes in component versions
License violation detection at the component level
OpenSSF Scorecard for open-source health assessment
SBoM Beyond Security Teams:
Development: manage technical debt, reduce dependency scatter, consolidate package usage, simplify selection for new projects
Acquisitions & Mergers: too many outdated/EOL/unmaintained components signals high post-acquisition cost; mismatched tech stacks indicate talent costs; too many stacks reveal non-cohesive teams
Compliance: licensing policy enforcement at component level, GPL restriction awareness, potential rework cost from non-compliant licenses
Risk Management: quantify vendor software risk, assess risk tolerance by deployment context, evaluate trust boundaries for sensitive integrations
What’s Needed to Advance the Ecosystem:
Cross-team collaboration to assign dollar/rupee value to library changes, upgrades, distribution, and rewrites
Output formats for non-technical stakeholders: PDF, HTML, Excel — not just CLI pipelines
Better UX in tooling to make SBoM accessible beyond security practitioners
Shift from glamorizing technology to focusing on practical usage
SBoM Play — Practical Demonstration:
Open-source tool by Cyfinoid (github.com/cyfinoid/sbomplay) for hands-on SBoM exploration
Downloads organization-level SBoMs, stores them in SQLite, and generates actionable reports
Demonstrates that working with SBoMs is straightforward — the hard part is quantifying business value
Actionable Takeaways
Move beyond SBoM generation and focus on the consumption stage — generating SBoMs without processes for using them delivers no security or business value.
Use SBoM quality tools like sbomqs and sbom-scorecard to validate that generated SBoMs are accurate and complete before relying on them for decisions.
Deploy policy-driven tools like Vet (SafeDep) to automate security policy enforcement based on SBoM data, rather than relying on manual review.
Adopt format-agnostic tooling like bomctl and sbomasm to handle multi-format SBoM environments and merge SBoMs across organizational boundaries.
Present SBoM insights in business-friendly formats (PDF, Excel, dashboards) to enable adoption by development, legal, M&A, and executive stakeholders.
Assign monetary value to SBoM findings — cost of upgrading libraries, licensing rework, post-acquisition technical debt — to justify investment and drive organizational buy-in.
Try SBoM Play (cyfinoid/sbomplay) to quickly explore your organization’s SBoM data in SQLite and generate reports that demonstrate cross-functional value.
Monitor EOL code and package drift using tools like xeol alongside your SBoM pipeline to catch components that silently become unsupported or change unexpectedly.
