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.
Full article187 words · extracted from arxiv.org · click to collapse
Software 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. In this paper, we evaluate three widely used SBOM generators across more than 3,000 JavaScript and Rust projects, using a groundtruth baseline derived from dependency lockfiles. Our results show that these tools diverge in terms of both dependency coverage and SBOM completeness. Importantly, most of these discrepancies are systematic rather than accidental: they arise from differing assumptions regarding dependency scope, naming, provenance, and representation, while others reflect inconsistent support for fields defined in SBOM specifications. These findings demonstrate that many of the observed discrepancies cannot simply be ''fixed'': they require clearer standardization. As SBOM generation becomes a legal compliance requirement, the choice of tool itself can influence the resulting SBOM, potentially becoming a source of undetected non-compliance. We argue that future SBOM standards should define canonical rules regarding dependency scope, provenance, and representation to improve interoperability and compliance.
Text extracted automatically; images, tables and formatting may be missing. Original: https://arxiv.org/abs/2609.19920