In our 8th annual State of the Software Supply Chain report, we detailed government regulations that are coming to protect national interests globally. Because software is frequently built from open source components, one key effort is tracking and managing those components.
One way to manage those is via a “software bill of materials” or SBOM.
SBOM standards were introduced to define a unified structure for SBOM generation and determine how these SBOMs are shared with end users. They also describe the software composition in a format that other tools can understand.
Through an Executive Order, the U.S. now requires SBOMs for government agencies, as well as those that contract with government purchasing for software. A goal they hope will improve the software industry as a whole:
“Though U.S. federal contractors will be the first required to create SBOMs, advocates have a global vision for including them in the software development process. As the existing standards become more popular, making an adjacent SBOM for each new software component will become best practice. The result will be a more robust ecosystem built on transparency.” (source)
One of our predictions for 2023 is that this is the year of the SBOM. Although there are many requirements, no specific SBOM format is recommended by a federal organization. The three items listed below are recognized in a variety of industries, and each is explicitly mentioned in the Software Bill of Materials Elements and Considerations by the US Federal Government. And because there are different available formats for detailing software components, we have compiled a list of possible reasons you may choose one format over another.
CycloneDX
CycloneDX is a “standard that provides advanced supply chain capabilities for cyber risk reduction. CycloneDX is a lightweight software bill of materials (SBOM) standard designed for use in application security contexts and supply chain component analysis.” (source)
The standard is backed by the OWASP Foundation with support from a global community. Features include:
-
Specifically built for SBOMs – with component identity.
-
Lightweight protocol – meaning it’s easy to build, maintain, and manage.
-
Multiple formats – JSON, XML, and broad support enable easy integration with other development tools.
-
Open source – released under an Apache 2.0 license.
-
Wide industry support – Intel, IBM, Sonatype, and more.
-
Security – with available digital signatures for the XML and JSON formats.
More on the OWASP – CycloneDX.
SPDX
Software Package Data Exchange or SPDX is “an open standard for communicating software bill of materials information, including provenance, license, security, and other related information. SPDX reduces redundant work by providing common formats for organizations and communities to share important data, thereby streamlining and improving compliance, security, and dependability.” (source)
SPDX is a Linux Foundation project. Its main attributes are:
-
Compliance – This involves robust intellectual property and license focus management. SPDX has its roots in license compliance, and this is its strongest area.
-
Comprehensive – SPDX provides a high amount of depth and analysis, including file-level details for license information.
-
Already familiar – SPDX is part of multiple industries, including some healthcare and automotive sectors for license compliance.
-
Open source – It is released under a Creative Commons Public License.
-
Supports comments and code snippets – It contains details about decisions, reviewer notes, and more (also coming soon in CycloneDX).
More on SPDX from the Linux Foundation.
Other related standards
While CycloneDX and SPDX are the two primary and officially recognized SBOM formats, there are two additional standards to keep in mind. These are SWID and purl:
Software Identification (SWID)
“… defines a structured metadata format for describing a software product. A SWID tag document is composed of a structured set of data elements that identify the software product, characterize the product's version, the organizations and individuals that had a role in the production and distribution of the product, information about the artifacts that comprise a software product, relationships between software products, and other descriptive metadata.” (source)
In a nutshell, Software Identification (SWID) is a standard for uniquely identifying and describing software applications and their components. It provides a standardized way to represent essential information about software products, such as their name, version, and other attributes.
SWID has various applications in software management, security, compliance, and reporting. It also plays a crucial role in ensuring transparency and accuracy in software asset management and security practices.
More on SWID (NIST.gov).
Package URL (purl)
“… is an attempt to standardize existing approaches to reliably identify and locate software packages.
A purl is a URL string used to identify and locate a software package in a mostly universal and uniform way across programming languages, package managers, packaging conventions, tools, APIs and databases.
Such a package URL is useful to reliably reference the same software package using a simple and expressive syntax and conventions based on familiar URLs.” (source)
Purl brings consistency, uniformity, and reliability to the identification and location of software packages. Purl identifiers are supported by both CycloneDX and SPDX. They are rapidly becoming the standard to describe open source components across various ecosystems in a convention that embraces the existing naming conventions from those ecosystems.
More on purl.
Do I have to choose?
Although some companies we researched use multiple formats, this could mean additional complexity. Just like some countries have had to choose between Fahrenheit or Celsius, switching between them mid-stream can mean extra work and potential loss of capabilities or fidelity.
Which is right for me?
Because the SBOM standard focuses on communication between projects, it can be worthwhile to speak with industry partners about their choices. For example, customers who work directly with Microsoft may be better served with SPDX, while IBM partners are likely to embrace CycloneDX.
If you were to choose, however, here’s how we would break down the decision:
SPDX (Software Package Data Exchange)
SPDX is a well-established and widely recognized standard for creating SBOMs. It offers a comprehensive and mature framework for describing software components, their licenses, and related metadata.
As mentioned earlier, SPDX is often favored in scenarios where you need to interact with industry giants like Microsoft, as it's supported by Microsoft and various other major tech companies.
CycloneDX
CycloneDX is a newer, lightweight SBOM standard that is gaining popularity, particularly in the open source community. It provides a simpler and more concise format for describing software components and their dependencies.
CycloneDX is known for its flexibility and agility, making it a practical choice for organizations that value simplicity and agility in their SBOMs.
Again, if you have partnerships or collaborations with companies like IBM or if you operate in environments where open-source and agile practices are prevalent, CycloneDX could be a more natural fit.
Where does Sonatype stand?
Sonatype and its employees have been a part of supporting CycloneDX since early in its development. We use CycloneDX as the basis of our third-party API and support for import and export. We’ve also contributed code and the initial security extension for including vulnerability details.
However, we are not exclusively focused on CycloneDX to the exclusion of other standards. As members of the Linux Foundation and Open Source Security Foundation, we also participate in the SPDX Working Group and are anxiously awaiting the upcoming v3.0 specification.
What is the future of SBOMs?
SBOMs are moving in line with the future of computing to try and observe and understand changes in security and development. Some changes on the horizon:
-
Cryptographic bill of materials – crucial for security in a post-quantum computing world.
-
Automation and integration – SBOMs that address machine learning tools. Automation will be a key component of this integration.
-
SBOMs for “low code” platforms that help enable tools for less technical staff and faster automation for software engineers.
- Industry standardization – efforts to standardize SBOM formats and practices will likely continue, making it easier for organizations to exchange and interpret SBOM data across the software ecosystem.
- Supply chain integrity – with an increasing emphasis on supply chain security, SBOMs will be used to verify the integrity of software components throughout their lifecycle. This will be particularly important in critical infrastructure and sensitive industries.
Here on the Sonatype blog, we’ll share more in the coming weeks on how to reduce legal risk with SBOMs.
---
Update: This article formerly stated that CycloneDX only supports XML digital signatures.
