Mind the Gap: How SBOM Specification Ambiguities Lead to Divergent Software Bills of Materials. An Empirical Tool Study
Empirical study of three SBOM generators across 3,000+ JavaScript and Rust projects finds systematic divergences caused by specification ambiguities, risking CRA non-compliance.
Researchers evaluated three widely used SBOM generators on more than 3,000 JavaScript and Rust projects, comparing outputs against a ground-truth baseline derived from dependency lockfiles. The tools diverged in dependency coverage and SBOM completeness, with most discrepancies stemming from differing assumptions about dependency scope, naming, provenance, and representation rather than implementation errors. SBOMs become mandatory in December 2027 under the European Cyber Resilience Act, meaning tool choice can itself cause undetected non-compliance. The authors argue SBOM standards need canonical rules for scope, provenance, and representation.
- Three SBOM generators tested against lockfile ground truth on 3,000+ JS and Rust projects.
- Discrepancies are mostly systematic, from differing scope, naming, and provenance assumptions.
- Tool choice can yield undetected non-compliance once CRA mandates SBOMs in December 2027.
- Authors call for canonical standardization rules rather than generator fixes.
- Products
- SBOM
- Countries
- European Union
From the original article
1 min read at arxiv.orgSoftware Bill of Materials (SBOMs) will become mandatory starting in December 2027 under the European Cyber Resilience Act (CRA) [8]. Although previous studies have highlighted significant differences among SBOM generators, the reasons for these discrepancies remain unknown, as does whether they stem from implementation errors or deliberate design choices.
By Alan Prado · arxiv.org
A short excerpt; the article and its images belong to the publisher. Summary, key facts and assessment above are AI-written from the article and can be wrong.