From Inventory to Policy: The Remarkable Evolution of SBOMs

This talk traces the 15+ year journey of Software Bills of Materials (SBOMs) from their origins as license compliance documents to their current role as critical risk assessment tools and now, under the EU Cyber Resilience Act, policy instruments that determine whether software clears customs. We'll explore how a simple "ingredient list" evolved through four distinct phases (license tracker, inventory list, compliance checkbox, and now risk document), why that changes everything for open source maintainers, and how starting December 2027, your SBOM becomes the difference between "clear to ship" and "stuck at the border" when authorities inspect component risks for every product exported to the EU.

Following are the key takaways from the talk:

1. The SBOM conversation has shifted

It's no longer "Do you have one?" It's "Can I trust it? Who can see it? What risk does it reveal?"

2. FOSS Projects are downstream SBOM providers

Whether you know it or not, your project's consumers are being asked for SBOMs and yours is part of theirs.

3. Component Quality is the new frontier

An SBOM can be 100% compliant and still be dangerous. Static validation is no longer enough, real-time checks for EOL, KEV, and malicious packages are essential.

4. The CRA can affects Indian FOSS Too

If your software is consumed by EU companies (directly or indirectly), you may be part of their compliance chain. The December 2027 deadline is approaching.

5. Actionable Next Steps for Maintainers

• Start generating SBOMs at build time, not as an afterthought

• Use OSS tools like syft for sbom generation, sbomqs for quality & compliance validation

• Resources: ENISA guidance, OpenChain templates, any standard compliance