Understanding Software Bill of Materials (SBOM) standards: CycloneDX, SPDX, SWID

What are SBOM standards? What’s the difference between CycloneDX, SPDX, and SWID?

Background on SBOMs and standards

Organizations across industries rely on open source and third-party software, yet lack basic visibility into the quality, security or creator of the software components. The lack of transparency makes software supply chains easily susceptible to attacks. To combat this, President Biden’s Executive Order on Improving the Nation’s Supply Chain recommended adopting Software Bill of Materials (SBOMs) as a way to identify and describe software components. 

The National Telecommunications and Information Administration (NTIA) defined the minimum elements for SBOMs as: identifying the supplier of the software component, identifying details about the version of the component, component unique identifiers, any component dependency relationships, and a timestamp of when and by whom the SBOM report was created. Since SBOMs are intended to be shared across companies and communities, having a consistent format (that is both human and machine readable) with consistent content is critical. The NTIA guidelines specify three standards as approved formats: SPDX, CycloneDX and SWID.

The NTIA selected CycloneDX, SPDX and SWID out of numerous standards actively being worked on. These three standards were developed by different open source projects and government agencies to solve for use cases that precede the Executive Order. While all three satisfy the minimum SBOM guidelines, they differ in terms of process, output, scope of coverage and have different roadmaps. 

To empower customers with the ability to assess, compare, and manage SBOMs from multiple suppliers, SettleTop actively supports all three standards (though, we’re most excited about CycloneDX).

CycloneDX

• Definition: CycloneDX is a lightweight SBOM standard designed for use in application security context and supply chain component analysis.

• History: 

  • CycloneDX was originally intended to solve for vulnerability identification, license compliance, and outdated component analysis for open source components.

  • The core working group originated from the OWASP community in 2017, then became its own dedicated open source project once the benefits of widespread adoption became clear.

  • CycloneDX has been more focused on vulnerabilities and security in addition to open source.

• Working group: core team is led by people from OWASP, Sonatype and ServiceNow

• How to use it: CycloneDX can be represented in different file formats (.XML, .JSON, and protocol buffers); the source code for CycloneDX is available on GitHub 

• What is it:

  • BOM Metadata: supplier, manufacturer, and target component, tools used to create the BOM, license information for the BOM

  • Components: describes the inventory of first-party and third-party components. Component identities are described as:

    • Coordinates (group, name, version)

    • Package URL

    • Common Platform Enumeration (CPE)

    • SWID (ISO/IEC 19770-2:2015)

    • Cryptographic hash functions (SHA-1, SHA-2, SHA-3, BLAKE2b, BLAKE3)

  • Services: describes the external APIs (endpoint URIs, authentication requirements, trust boundary traversals) that the software calls and the flow direction of the data

  • Dependencies: describes how components depend on other components through a dependency graph that represents direct and transitive relationships

  • Extensions: extension points to support future use cases and functionality

Source: CycloneDX.org

SPDX - Software Package Data Exchange 

• Definition: SPDX provides a standard language for communicating the components, licenses, copyrights, and security information associated with software components in multiple file formats.

• History: 

  • The Linux Foundation has been developing and refining SPDX since 2010. According to the Linux Foundation, “SPDX was created to provide a common data exchange format so information about software packages and related content could be collected and shared.” 

  • The core focus of SPDX has and continues to be open source licence compliance.

• How to use it: the SPDX document can be expressed in multiple file formats (RDFa, .xlsx, .spdx) and is expanding into others (including .xml, .json, and .yaml). There’s an online tool and GitHub repository.

• What is it:

  • SPDX Document Creation Information: metadata to associate analysis results with a specific version of the SPDX file and details on how, when, and by whom the SPDX file was created.

  • Package Information: facts that are common properties of an entire package

  • File Information: facts that are specific to files which may be included in packages

  • Snippet Information: facts that are specific to only a part of a file

  • Other licensing information detected: a way to capture information about and refer to other licenses that are not on the SPDX License List

  • Relationships Between SPDX Elements: Information on how documents, packages and files relate to each other

  • Annotations: information about when and by whom the SPDX file was reviewed

Source: Linux Foundation

SPDX Lite

• Definition: SPDX Lite is a lightweight subset of the SPDX for situations where the full SPDX is not required. It’s intended to be easy to use by those without open source license knowledge or experience and to be “the balance between SPDX standard and actual workflows in some industries.”

• History:

  • Contributions have largely been led by the industry participants in the OpenChain Japan working group including Hitachi, Fujitsu, Sony, Renesas and Toshiba.

  • SPDX Lite is Included in the 2.2 release.

• What is it:

  • Mandatory fields from Document Creation and Package Information in order to be compatible with other SPDX documents and exchange license information.

    • Document Creation: SPDX version, data license, SPDX identifier, document name, SPDX Document Namespace, Creator

    • Package Information: package name, package version, package file name, package download location, package home page, concluded license, declared license, comments on license and copyright text

Source: Linux Foundation

SWID - Software Identification Tags 

• Definition: 

  • According to NIST, “the SWID standard defines a lifecycle where a SWID tag is added to an endpoint as part of the software product’s installation process and deleted by the product’s uninstall process.”

  • Standard indicators of a software product’s presence on a device through a consistent label with details on the product name and version.

• History: 

  • SWID tags aim to help enterprises create accurate software inventories by making it easier to discover, identify and contextualize software throughout the software lifecycle. The standard is part of the broader ISO IT asset management standard and is supported by NIST.

  • The first version of SWID was published in 2009, then revised in 2015.

• Includes:

  • Corpus Tags: describes software in the pre-installation phase (TAR, ZIP file, executable file)

  • Primary Tags: provides the name of the product, a globally unique identifier for the tag, and basic information identifying the tag’s creator

  • Patch Tags: identifies and describes the patch applied to a product

  • Supplemental Tags: additional details to augment the primary or patch tags

Source: NIST