SBOM Standard Formats – A Guide
A software bill of materials – or SBOM – plays an important role in providing much-needed visibility into the details of software components and the supply chain. As an SBOM is developed, it should adhere to a format or SBOM standard that defines a unified structure for how it will be generated and shared with customers.
There are three main SBOM formats:
- Software package data exchange (SPDX)—an open source machine-readable format with origins in Linux.
- Software identification tags (SWID)—an industry standard used by different commercial software publishers
- CycloneDX (CDX)—an open source machine-readable format with origins in the Open Web Application Security Project (OWASP) community
Even though these three formats contain overlapping information, they have traditionally been used at different points in the SDLC and are consumed by different types of users, according to the NTIA Software Transparency Working Group on Standards and Formats.
How do you know which is right for you? All three formats can be used to generate, exchange and use SBOM data, but certain use cases may lend themselves to a particular format.
All About the SPDX SBOM Standard Format
SPDX was developed by the open source software development community for “ease of ingestion within a developer workflow and within corporations to support compliance and software transparency for open source and proprietary code,” according to the NTIA working group. Given its open source roots, the format is supported by a wide and distributed population of commercial international organizations, as well as developers who may not be associated with vendors, the NTIA said.
Importantly, the accessibility of SPDX means that a developer of an experimental library can generate an SBOM without much effort, free of charge. The availability of open source tools and cost-saving makes it attractive to organizations, along with the ability to link artifacts to global reference systems via Common Platform Enumeration (CPE), Package URL (purl), Software Heritage persistent ID (SWHID), as well as other package build coordinates. This enables flexibility to handle security use cases.
SPDX became an internationally recognized standard for SBOM published as ISO/IEC 5962:2021 in September 2021.
Besides Rezilion, its supporters include Cisco, Google, Intel, Microsoft, SAP, Siemens, Sony, VMware and MITRE
All About the CycloneDX SBOM Standard Format
CycloneDX is an open source standard developed by the OWASP foundation. It supports a wide range of development ecosystems, a comprehensive set of use cases, and focuses on automation, ease of adoption, and progressive enhancement of SBOMs throughout build pipelines. The specification is widely used among organizations with security use cases and is equally capable of describing both open source and proprietary software.
A large and growing collection of community and officially supported open source tools are available, and the project’s website includes many examples for achieving various use cases. CycloneDX natively supports multiple standards for component identity including coordinates, Package URL, CPE, and SWID for both binary and source software artifacts.
In May, OWASP CycloneDX launched a BOM Exchange API that aims to operationalize an SBOM. It also standardizes how BOMs are published and retrieved in a software agnostic ecosystem.
In addition to Rezilion, supporters include Google, Intel, IBM, Red Hat, Oracle, Cisco and SAP.
All About SWID Tags
SWID tags were designed to provide a transparent way for organizations to track their software inventory on managed devices. SWID tags contain descriptive information about a specific software release such as the product and version. It also identifies the organizations and individuals that played a role in producing and distributing the product.
The SWID standard defines a product lifecycle when it is added to an endpoint during the product’s installation and then deleted when the product is uninstalled.
NIST recommends adoption of the SWID Tag standard by software producers, and multiple standards bodies, including the Trusted Computing Group (TCG) and the Internet Engineering Task Force (IETF) utilize SWID Tags in their standards.
A developer can use readily available guidance on how to develop SWID tags to configure their build pipeline to produce SWID tags automatically during the software build and packaging process. Geared at deployed software, SWID tags follow the binary artifact and are updated as changes are made to the compiled codebase. This lends itself to integration with automated scanning, and a variety of risk management use cases and tooling, NIST said.
NIST is working with the IETF to develop multiple specifications that use SWID Tags. It is also working to incorporate SWID Tag data into the National Vulnerability Database’s (NVD) vulnerability dataset and has incorporated the use of SWID Tag data into Security Content Automation Protocol (SCAP) version 1.3.
The NTIA has made a point of not endorsing any of these standards. It is up to individual organizations to determine which one best meets their needs.
A Dynamic SBOM Leads to Better Software Security
Regardless of format, in order for an SBOM to offer security, it must be dynamic. In fact, SBOMs that are not dynamic—able to easily and automatically account for the constant change swirling around the software landscape—are of minimal use. They’re static entities in the midst of ongoing shifts. It’s the “dynamic” and automation part of these documents that make them true security tools.
For more information on Rezilion’s Dynamic SBOM, visit https://www.rezilion.com/platform/dynamic-sbom/ and to sign up for a free 30-day trial visit https://www.rezilion.com/get-started/.
