By listing the components included in an application, Software Bills of Materials (SBOMs) are intended to support the timely identification of vulnerable components and ensure the security of the software supply chain. However, we question the underlying assumption that there is agreement on the components to be listed in an SBOM and that current technology is sufficient to secure the software supply chain. First, we propose a ground-up analysis of Component Inclusion Mechanisms (CIM) in the software's development lifecycle. Then we systematically analyze the four popular SBOM generation tools, cdxgen, syft, trivy, ORT, and the Microsoft sbom-tool, to understand how they define and identify relevant components. Finally, we assess these using a ground truth across the programming languages Python, Java, Go, PHP, Rust, and C. While today's tools are a step toward identifying components, our results show that no tool covers all identified CIMs and that common gaps exist across tools. We demonstrate that, under the current vague definitions and tooling, SBOMs exhibit ambiguity and blind spots in component inclusion. Thus, a security-grade SBOM is not achievable with the evaluated tools, necessitating further progress to ensure software supply chain security. We need to go back to the drawing board to clarify which components should be included in an SBOM and revise SBOM generators accordingly. Without a shared understanding of what a component is, any effort to secure software supply chains with SBOMs will fail.

翻译：通过列出应用程序中包含的组件，软件物料清单（SBOM）旨在支持及时识别易受攻击的组件，并确保软件供应链的安全性。然而，我们质疑其潜在假设——即对于SBOM中应列出的组件存在共识，且当前技术足以保障软件供应链安全。首先，我们对软件开发生命周期中的组件纳入机制（CIM）进行了基础性分析。随后，我们系统性地评估了四种主流SBOM生成工具——cdxgen、syft、trivy、ORT以及微软的sbom-tool，以理解它们如何定义和识别相关组件。最后，我们基于涵盖Python、Java、Go、PHP、Rust和C编程语言的真实基准数据集对这些工具进行了评估。尽管当前工具在组件识别方面迈出了一步，但我们的结果表明，没有任何工具能覆盖所有已识别的组件纳入机制，且不同工具间存在共同的遗漏。我们证明，在现有模糊定义和工具条件下，SBOM在组件纳入方面存在歧义和盲点。因此，使用这些评估工具无法实现安全级别的SBOM，这需要进一步推进以确保软件供应链安全。我们必须回归设计初衷，明确SBOM应包含哪些组件，并相应修订SBOM生成器。若对何为组件缺乏共同理解，任何利用SBOM保障软件供应链安全的努力都将失败。