Bsides Bangalore Sbom Fad Future

This presentation at Bsides Bangalore examines the Software Bill of Materials (SBoM) phenomenon with a balanced perspective — exploring whether it is merely a regulatory fad or a transformative force for the IT industry. Anant Shrivastava walks through what SBoM is, the competing standards landscape, industry skepticism, and crucially, how SBoM can deliver value far beyond security teams when positioned as an organizational inventory tool for development, M&A, compliance, and risk management.

Key Topics Covered

SBoM Fundamentals:

• An SBoM is an itemized list of all third-party components in software, capturing name, version, checksum, license, and dependency information
• SBoMs typically cover one level of depth, with deeper levels plugged into each other
• Three competing standards exist: SPDX (ISO standard, GitHub default), CycloneDX (OWASP-backed), and SWID (alternative ISO specification)

Generation and Tooling:

• GitHub provides dependency graph exports via the Insights tab
• Key generation tools include cdxgen (CycloneDX) and SPDX Generator
• As a last resort, SBoMs can be hand-crafted since the underlying format is XML

Industry Skepticism and Challenges:

• SBoM rose to prominence due to the US Presidential Executive Order, but the mandate focused on creation without guidance on usage or consumption
• Common industry pushback includes concerns about disclosing software composition, NDA restrictions on sharing, geographic irrelevance (“we don’t sell to USA”), and preferring to fix bugs over building SBoMs
• The infosec community has never had well-maintained inventory and lacks experience leveraging it once created

The Self-Created Problem Cycle:

• Software build automation drives faster release cycles, which reduces inclination to upgrade dependencies
• Over-reliance on OSS without supporting maintainers, impossible segregation of features and bug fixes, and the “hedonic hamster wheel” of automated vulnerability notifications

SBoM Value Beyond Security:

• Security is seen as a cost center; positioning SBoM as useful for profit centers (HR, Finance) makes it harder to eliminate
• For developers: manage technical debt, reduce dependency scatter, consolidate usage, simplify package selection
• For M&A: assess future ownership costs through outdated/EOL/unmaintained software indicators, evaluate tech stack diversity and team cohesion
• For compliance: track licensing policy at component level, identify GPL and other restriction risks, estimate rework costs
• For risk management: quantify risk of vendor software purchases, evaluate visibility vs. risk trade-offs, assess SSO token exposure

Evolving Security Ecosystem:

• VDR (Vulnerability Disclosure Report) and VEX (Vulnerability Exploitability eXchange) complement SBoM
• The xBoM family is expanding: SaaSBOM, HBOM, ML-BOM, CBOM, MBOM, OBOM
• Attestations are emerging as additional trust signals
• Existing tools include OWASP CycloneDX, Google SLSA, SPDX, SafeDep, Dependency Tracker, and SYFT

What Is Needed:

• Better tooling with improved UX — current tools are not easy even for practitioners
• Cross-team collaboration and feedback from non-security stakeholders
• Focus on practical usage over technical glamour

Actionable Takeaways

1. Start generating SBoMs for your projects using tools like cdxgen or GitHub’s built-in dependency graph export to build a software inventory baseline.
2. Position SBoM value beyond security by demonstrating use cases for development teams (technical debt tracking), M&A due diligence, compliance (license auditing), and risk management.
3. Engage non-security stakeholders early — if business-critical departments depend on SBoM data, the initiative becomes harder to defund.
4. Explore companion standards like VEX and VDR to add vulnerability context on top of raw SBoM inventory data.
5. Invest in making SBoM outputs accessible through GUI-friendly formats (PDF, HTML, Excel) rather than CLI-only pipelines, to reach broader organizational audiences.