Wanted: An SBOM Standard to Rule Them All

COMMENTARY

The SBOM cometh, and there's no going back. Originally created by the National Telecommunications and Information Administration (NTIA), the software bill of materials (SBOM) went from niche to mandatory, seemingly in the blink of an eye. Federal agencies and security teams now require SBOMs from third-party vendors as part of their audits and approval processes. More and more enterprises are adding SBOM generation to their security checklist for any included components — even for software-as-a-service (SaaS) providers. This is logical. The rise of nasty supply chain attacks like Log4j and xz underscores the necessity of SBOMs.

However, to date, the SBOM has largely failed to deliver on its promise because of competing standards and varied implementation methods across a wide variety of tools. These issues have turned what was meant to be a gold standard of transparency into a confusing exercise in ETL and data schema management. This is not good. SBOMs are critical to the future of cybersecurity. The tech world must recognize the SBOM's critical importance and adopt a unified, comprehensive format. Here's how we can achieve that.

The Case for a Unified SBOM Standard

The SBOM concept emerged in the early 2000s as a "parts catalog" for software, inspired by the manufacturing industry. The vision extended beyond a mere list to include a programmatic mechanism for automatic verification of software components, their versions, and their security statuses. This system would catch problems like typosquatting attacks, where developers inadvertently download malicious packages, and more complex attacks like the xz incident, where attackers gain access to trusted repositories and make subtle changes. An SBOM would rapidly identify and trace exposure, a critical capability highlighted by the Log4j attack, where teams struggled to locate the vulnerable library in their systems.

The past decade's trends have made SBOMs more urgent. Software development has shifted from monolithic proprietary codebases to a heavy reliance on open source, including libraries and modules. Every layer of the software stack now prominently features open source components. Microservices and the "shift-left" movement have added more components to the software supply chain, breaking applications into smaller pieces and allowing teams to choose their components. Consequently, a significant portion of modern applications are built and controlled by third parties, whose reliability and trustworthiness can vary.

Reconciling Competing Standards Is Costly, Time Consuming

Two major SBOM standards have emerged, each backed by influential industry groups. SPDX (Software Package Data Exchange), introduced in 2010 by the Linux Foundation, communicates detailed SBOM information, including components, licenses, copyrights, and security references. CycloneDX, developed by OWASP in 2017, is another SBOM standard designed for easy integration into existing development tools and processes. In theory, these standards are compatible and can coexist in the same enterprise security stack. In practice, this is rarely the case.

Organizations often face significant challenges when combining or exchanging data between SPDX and CycloneDX formats due to their different structures, focus areas, and levels of detail. SPDX, rooted in open source license compliance, provides comprehensive component data down to file-level details and code snippets. In contrast, CycloneDX, originating from the security community, is optimized for vulnerability identification and analysis, featuring robust elements like digital signatures and vulnerability exploitability data. Mapping fields and translating information between these formats can be complex, especially for large and intricate SBOMs. Changing data schemas can disrupt integration efforts or confuse downstream tools, such as compliance platforms, SIEM, or SOAR systems.

Additionally, tooling limitations, format versioning, depth of information discrepancies, and organizational preferences for specific formats further complicates interoperability efforts. Although the NTIA version promotes consistency across SBOM standards, the inherent differences between SPDX and CycloneDX remain challenging to reconcile. The minimalist nature of SBOM requirements leaves ample room for interpretation, resulting in divergent implementations across industries even as they track the same software components.

Create a Standards Body and Tip the Scales

From 5G to HTML to containers, single standards ensure compatibility and conformance for foundational capabilities. The first step in achieving this for SBOMs is recognizing their critical importance. Next, a single industry or collaborative body must be designated to unify the standards. This process will likely be slow and messy due to the diverse interests at stake. A good analogy is the ongoing work of the World Wide Web Consortium (W3C) around Web standards. Initially, this effort should reconcile the competing origins of major SBOMs into a clearer vision and a distinct declaration of what an SBOM should accomplish.

Broad industry participation is crucial, but the involvement of large incumbents is essential. Cloud hyperscalers, major cybersecurity firms, and developer tooling giants (like GitHub, GitLab, Atlassian, Microsoft, and Google) must participate, because developers, security operations, DevOps, and platform teams are the primary consumers and users of any unified SBOM format. The ultimate test is whether the new SBOM format reduces toil and enhances security and transparency compared to current SBOMs. Network effects and compliance standards, such as SOC2 or ISO, promoting a new unified standard, would strongly influence adoption and potentially tip the scales toward a unified approach.

A unified SBOM standard is essential to realize the full potential of SBOMs in enhancing software supply chain security. By simplifying on a single standard, tooling makers and development teams could save considerable effort and resources. Overcoming the challenges of multiple standards and fragmentation would promote clarity, consistency, interoperability, and ultimately, a more secure software ecosystem.