Poking Around in the Dark: Why a Shared Understanding of Components Matters
2026-06-01 • Software Engineering
Software EngineeringCryptography and Security
AI summaryⓘ
The authors examine how tools that create Software Bills of Materials (SBOMs) decide which parts of a software should be listed. They tested five popular tools across several programming languages and found that none of them catch all the components, leaving gaps and unclear parts. This means current SBOMs might miss important details needed for tracking security issues. The authors argue that before SBOMs can really help secure software supply chains, we need clearer rules about what to include and better tools to follow those rules.
Software Bill of Materials (SBOM)software supply chaincomponent inclusion mechanisms (CIM)SBOM generation toolscdxgensyfttrivyORTsoftware securityprogramming languages
Authors
Felix Reichmann, Wolfgang Krane, Alena Naiakshina, Martin Johns, Simon Koch
Abstract
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.