SBOM Tools Fall Short on Component Definitions, Threatening Supply Chain Security

Software Bills of Materials (SBOMs) are designed to catalog every component in an application to catch vulnerabilities quickly and protect the software supply chain. But a new study from researchers on arXiv challenges a fundamental assumption: that everyone agrees on which components should actually be included.

The Problem with Current SBOM Tools#

Researchers conducted a systematic examination of five widely-used SBOM generation tools—cdxgen, syft, trivy, ORT, and Microsoft's sbom-tool—across six programming languages: Python, Java, Go, PHP, Rust, and C. The analysis revealed significant inconsistencies in how these tools define and identify relevant components.

The core issue is that no single tool captures all Component Inclusion Mechanisms (CIMs)—the various ways software pulls in dependencies throughout development. Tools have common blind spots, and they frequently disagree on what counts as a component worth documenting.

Why This Matters for Security#

Because there's no shared understanding of what constitutes a "component," the resulting SBOMs suffer from ambiguity and incomplete visibility. This fragmentation undermines the entire premise of using SBOMs for supply chain protection. A vulnerability could hide in a component one tool recognizes but another misses—and if an SBOM doesn't list it, security teams won't know to investigate.

The Path Forward#

The researchers conclude that current tools represent progress but fall short of delivering what would be needed for genuine security-grade SBOMs. The field needs to return to basics: establish clear, agreed-upon definitions of what a component is, then rebuild SBOM generators around that foundation. Without that shared language, efforts to use SBOMs as a bulwark against supply chain attacks will continue to fail.

Read the full research paper on arXiv