Poking Around in the Dark: Why a Shared Understanding of Components Matters

2026-06-01

AI Summary

Current Software Bill of Materials (SBOM) tools struggle to comprehensively identify security vulnerabilities due to the absence of a unified standard for component identification, thereby jeopardizing software supply chain security. This work introduces the Component Introduction Mechanism (CIM) analysis framework—the first of its kind—to systematically evaluate the component detection capabilities of cdxgen, syft, trivy, ORT, and Microsoft’s sbom-tool across real-world projects in six programming languages: Python, Java, Go, PHP, Rust, and C. The study reveals that existing tools commonly suffer from incomplete CIM coverage, ambiguous component definitions, and shared blind spots, leading to significant ambiguities and omissions in generated SBOMs. These findings underscore the urgent need for community-wide consensus on component identification and provide an empirical foundation and strategic guidance for developing more reliable SBOM technologies.

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.

Problem

• Software Bill of Materials
• component identification
• software supply chain security
• component inclusion
• SBOM ambiguity

Innovation

• Software Bill of Materials
• Component Inclusion Mechanisms
• SBOM generation
• software supply chain security
• component identification