Search papers, labs, and topics across Lattice.
This paper critiques the effectiveness of Software Bills of Materials (SBOMs) in ensuring software supply chain security by analyzing the Component Inclusion Mechanisms (CIM) across various SBOM generation tools. The authors systematically evaluate tools like cdxgen, syft, trivy, ORT, and the Microsoft sbom-tool, revealing that none adequately cover all CIMs, leading to significant gaps and ambiguities in component identification. The findings highlight that without a consensus on component definitions, current SBOMs cannot achieve the necessary security standards, calling for a reevaluation of both component criteria and SBOM generation methodologies.
Current SBOM tools leave critical gaps in component identification, jeopardizing software supply chain security.
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.
