Mind the Gap: How SBOM Specification Ambiguities Lead to Divergent Software Bills of Materials. An Empirical Tool Study

2026-09-17

AI Summary

研究通过对比分析三种SBOM生成工具在JavaScript和Rust项目中的表现，揭示了因SBOM规范模糊导致的系统性差异问题，并建议未来需明确标准化规则以提高互操作性和合规性。

Abstract

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.

Problem

• SBOM
• specification ambiguities
• dependency scope
• provenance
• representation

Innovation

• SBOM Generators
• Dependency Coverage
• SBOM Completeness
• Standardization
• Compliance