Despite the growing adoption of the Software Bill of Materials (SBOM) to serve as a vulnerability management and cybersecurity tool, many organizations still struggle to understand the two most popular SBOM formats in use today, SPDX and CycloneDX. In this article, we will compare these two formats to help you choose the right one for your needs.
What are SBOM Formats
In developing Software Bills of Materials for Software development and vulnerability management, there’s a need to adhere to a specific format or standards. The standard SBOM formats define a specific and unified structure for SBOM generation and also determine how it will be shared with customers and users down the software supply chain. The SBOM formats also define the composition of the software in a format that is easy for other cybersecurity tools to understand. Generally, there are three SBOM formats. They include:
Software package data exchange (SPDX): this is an open-source, machine-readable SBOM project by the Linux foundation. It was designed primarily to ensure compliance and transparency in the management of open-source and proprietary code by development teams and corporations.
CycloneDX (CDX): this is also an open-source and machine-readable SBOM format developed by the Open Web Application Security Project (OWASP) community. It is a lightweight SBOM format focused on ease of adoption and automation of SBOM generation throughout your software development pipeline.
Software identification tags (SWID): SWID tags are considered more of a software identifier than an SBOM format. It does provide a simple and transparent way to track software inventory by storing specific information about the software release.
Generally, only the SPDX and CycloneDX SBOM formats are recognized officially. The SWID format’s primary use is for software identification because it does not offer as much information as the other two formats.
SPDX and CycloneDX contain overlapping information, and many have argued that they can be used interchangeably since there’s no single “standard” SBOM format. However, the two formats have traditionally different use cases within the software development lifecycle. Therefore, different organizations have to determine which one works best for them based on their unique cybersecurity and compliance needs.
Click here to learn more about SBOM standard formats.
SPDX vs. CycloneDx Comparison
SPDX and CyclonDX are the two standard formats for SBOM generation, and it’s likely to stay like this for a long time to come. Most SBOM generation platforms support both formats. However, they’re distinct tools with different use cases. Some of their core differences are highlighted below:
CycloneDX is an open-source SBOM project by one of the leading software security organizations, the Open Web Application Security Project (OWASP). The project was launched in 2017 as a component analysis platform to help users identify risks in the software supply chain. Vulnerability identification remains CycloneDX’s primary use case. This SBOM format also helps with license compliance and with the identification of outdated software components.
CycloneDX is focused on automation and easing up the adoption of SBOM requirements throughout the build cycle of software. The format is used by both open-source and proprietary software organizations for security use cases.
As a BOM format, CycloneDX has other applications beyond the preparation of software bills of materials. It can also be used to compile components, vulnerabilities, and services of hardware and cloud systems. SBOMs prepared in the Cyclone DX format list vulnerabilities in three main fields. These are:
- Common Platform Enumeration (CPE): Vulnerabilities within an application, hardware devices, or operating system.
- SWID: the Software identification tag is used to analyze the components of installed software
- Package-URL (PURL). CycloneDX also lists software package metadata.
In addition to this, the CycloneDX format also supports the provenance tracking of software products and their components. This makes it easier to identify the authors and suppliers of software and all its components.
SPDX stands for Software Package Data Exchange. It is an open-source project by the Linux Foundation created with the intent of serving as a common format for the collection and sharing of software data-especially licensing information.
The SPDX standard was originally developed in 2011 as an open-source license management tool. Over the years the format has been refined over the years to include new fields that improve the format’s ability to capture important security-related information and make it more interoperable with other standard SBOM formats.
In September 2021, the International Standard Organization recognized the SPDX format as an internationally recognized standard for SBOM publication. SPDX is the only SBOM format to have achieved this feat.
Now at version 2.2.2, the original version of the SPDX specification was developed to ease compliance with software licensing policies. Subsequent versions have added a few capabilities that make it useful for a wide range of use cases, including the identification of software vulnerabilities.
The latest version of the SPDX was designed in line with the NTIA’s standard for ‘Minimum Elements For a Software Bill of Materials.’ It lists the components, copyrights, licenses, and security references of a piece of software.
An SBOM document in SPDX format is expected to have specific fields and sections as highlighted below:
- Document creation information: This information is used to determine compatibility with standard processing tools
- Package information: the package information defines important entities that share the same context within the software package, such as the containers, components, and products.
- File information: identifying information for the software files, such as the name, license, and copyright information for each file.
- Snippet information: this is not always applicable. The snippet information is only necessary when the software data is from a different source.
● Relationships and annotations: An SBOM in SPDX format also indicates the relationship between the different documents, files, and packages used within the software with clear annotations that makes it easier for anyone to review the software component relationships.
|Information: The SPDX SBOM format captures information about the author of the software BOM, how it was created, and when it was created for each version of the SPDX file.||BOM metadata: CycloneDX format captures important information about the software manufacturer/supplier and target components. It also includes licensing information, and metadata of the tools used to create the bill of materials.|
|Package information: includes data related to the common properties of the entire software package.||Components: outlines all the components of the software across the entire supply chain.|
|File information: data relating to all files included in the software package.||Services: outlines external APIs, endpoint URLs, and authentication requirements. Trust boundary traversals and other external requirements of the software.|
|Snippet information: data related to a specific part of a file.||Dependencies: this field outlines the direct and transitive relationship between the different components of a software|
|Licensing information: A field to capture data about licenses not captured in the SPDX license list.||Extensions: Provides data about extension points which will be useful for future use cases and functionality.|
|Correlation between SPDX elements: the field shows how the different files, documents, and packages detailed in the SPDX documentation are linked to each other.|
|nnotations: additional information to explain how the SPDX document was reviewed, who reviewed it and when it was reviewed.|
What Is The Difference Between SPDX And CycloneDX?
The two standard SBOM formats highlighted above can be used to generate, share and manage SBOM data. They allow users to generate accurate information about the components of a software product. The SPDX (Software Package Data Exchange) format was primarily designed as a way to manage open-source software licenses and share information about the packages. CycloneDX, on the other hand, allows users to create SBOMs (Software Bill of Materials) that provide detailed information about Software Components.
Which Standard Is Better to Use?
Since the format you choose determines the structure of your SBOM document, its components, how it will be generated, and how it will be shared with users, it is important that you choose the right SBOM format for generating SBOM based on your organization’s unique needs.
Although SPDX and CycloneDX have very similar applications, they’re different in terms of their original use cases. The SPDX format was created back in 2011 as a license management tool. Today, it is still useful for sharing detailed information about the components of a software system with humans along the supply chain. This makes this format more useful for software development purposes.
CycloneDX (CDX), on the other hand, was developed more recently with the primary purpose of generating SBOM documentation which makes it a more efficient vulnerability management tool as it details all the standard components of a software product. The lightweight nature of CycloneDX also makes it an efficient tool for generating machine-readable Software Bills of Materials that you can share and process quickly
At the end of the day, there’s no “better” format between these two. Which one to choose depends largely on the specific needs of your organization and the intended use case of the SBOM document you intend to generate.
This content is brought to you by Scribe Security, a leading end-to-end software supply chain security solution provider – delivering state-of-the-art security to code artifacts and code development and delivery processes throughout the software supply chains. Learn more.
The rise of the SBOM—Our take on Gartner’s Innovation Insight report for SBOMs
With the growing use of third-party components and lengthy software supply chains, attackers can now compromise many software packages simultaneously via a single exploit. In response to this new attack vector, more development and DevOps teams, as well as security professionals, are looking to incorporate a Software Bill of Materials (SBOM). The software supply chain […]
What Happens When an AI Company Falls Victim to a Software Supply Chain Vulnerability
On March 20th OpenAI took down the popular generative AI tool ChatGPT for a few hours. It later admitted that the reason for the outage was a software supply chain vulnerability that originated in the open-source in-memory data store library ‘Redis’. As a result of this vulnerability, there was a time window (between 1-10 am […]
From Chaos to Clarity: How to Secure Your Supply Chain with Attestations
As everyone is getting progressively more aware, protecting your software supply chains should be a vital part of every organization’s cyber security strategy. One of the main difficulties in creating a comprehensive strategy to mitigate software supply chain threats is the complexity and diversity of supply chains. Each supply chain is unique, and the elements […]