What is an SBOM?
To build and maintain secure systems, you must know what software you’re using. If you can’t tell what’s installed, you’re driving blind. A software bill of material (SBOM) is the solution to this issue. It will keep track of any and all tools, libraries, and frameworks in use so you can check them for security vulnerabilities.
In its simplest form, an SBOM is just a list of all your organization's software components. It should at least include the name of each tool, library, or framework, along with the versions you’re currently using and their licenses.
SBOMs are a vital part of any serious software supply chain security program. In their digital form, SBOMs allow you to automatically check your installed software for potential security vulnerabilities as well as license issues. So, not only do they facilitate compliance, they also help companies avoid lawsuits due to the licensing information they contain.
Wiz’s agentless SBOM allows you to gain complete visibility of your applications’ components, including packages, open-source libraries, and nested dependencies, without blind spots and deploying an agent.
What are popular SBOM formats?
Two major formats dominate the SBOM ecosystem: Software Package Data Exchange (SPDX) and CycloneDX (CDX). Let’s check them out.
Software Package Data Exchange
SPDX was initially created by the Linux Foundation to track software licenses. Over the years, the SPDX specification received updates to track the integrity of files, security vulnerabilities, and relationships between software components.
CycloneDX
CDX is an SBOM format created by the OWASP Foundation to track software vulnerabilities. Like SPDX, the CDX specification has received updates over the years, including extensions to track other information, such as licenses. The primary difference between CDX and SPDX is that CDX favors a lightweight extension-based approach, while SPDX is more monolithic.
Software Identification Tags
SBOM comparisons often mention Software Identification (SWID) Tags alongside SPDX and CDX. However, a SWID tag is not an SBOM format. It supplies identifiers for software components, similar to ISBNs for books, and only contains version, creator, and licensor information.
How do SPDX and CDX differ?
Now that you know the most popular formats, let’s examine their differences.
Format
Both SPDX and CDX support their own flavors of JSON and XML. However, SPDX also supports YAML and plain text formats, which are easier for humans to read, as they have fewer markups around the information.
Let’s look at some examples.
SPDX
First, we have the XML format for SPDX, which is unwieldy with its namespaced tag names. The following code defines an SBOM for an example application with name, version, license, and download URL:
<?xml version="1.0" encoding="UTF-8"?>
<spdx
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="http://spdx.org/schema/spdx-2.2.xsd">
<spdx:identification>
<spdx:identifier>Example-SBOM</spdx:identifier>
<spdx:name>Simple Example Application</spdx:name>
<spdx:version>1.0</spdx:version>
</spdx:identification>
<spdx:packageDeclaration>
<spdx:name>com.example.SimpleApp</spdx:name>
<spdx:versionInfo>1.0.0</spdx:versionInfo>
<spdx:downloadLocation
href="https://github.com/example/simpleapp"/>
</spdx:packageDeclaration>
<spdx:licenseConcluded ref="MIT"/>
</spdx:spdx>Compared to the above, the plain text format for SPDX is far less cluttered:
SPDXVersion: SPDX-2.3
DataLicense: CC0-1.0
SPDXID: SPDXRef-DOCUMENT
DocumentName: Example Application SBOM
DocumentNamespace: urn:uuid:12345678-90ab-cdef-1234-abcd123456789
Creator: John Doe
Created: 2024-05-20T00:00:00Z
PackageName: com.example.SimpleApp
SPDXID: SPDXRef-Package-com_example_App
PackageVersion: 1.0.0
PackageSupplier: Example Inc.
PackageDownloadLocation: NOASSERTION
FilesAnalyzed: false
Relationship: SPDXRef-DOCUMENT DESCRIBES SPDXRef-Package-com_example_SimpleAppCDX
The XML format of CDX contains the same information, but is more lightweight than the SPDX XML format:
<?xml version="1.0" encoding="UTF-8"?>
<bom xmlns="http://cyclonedx.org/schema/bom/1.2">
<bomHeader>
<name>Simple Example Application</name>
<version>1.0</version>
<description>A simple example application.</description>
</bomHeader>
<components>
<component>
<id>com.example.SimpleApp</id>
<version>1.0.0</version>
<type>library</type>
<purl>bom:pkg/com.example/SimpleApp@1.0.0</purl>
<licenses>
<license>MIT</license>
</licenses>
</component>
</components>
</bom>Specification scope
The Linux Foundation's projects lean heavily on open-source licenses like the GNU General Public License (GPL), which requires users to publish source code. Therefore, the SPDX format was created to keep track of software licenses and give other organizations a tool for legal safety.
The OWASP Foundation is mainly concerned with the security aspects of software development, so it created the CDX format to help organizations track software vulnerabilities. White its core function is to cover code/binaries, CDX extensions for web services (i.e., any API you use in your application) are also available.
Over the years, SPDX and CDX have converged on their goals, with both now supporting licenses and vulnerabilities.
Adoption
SPDX is more widely adopted and supported than CDX. It’s also a standard of the International Organization for Standardization (ISO), which supplies implementors with detailed specification documents (ISO/IEC 5962:2021). This standardization has helped SPDX gain popularity in enterprise environments, where such standards are favored.
However, CDX’s lightweight approach and its backing from OWASP have helped it gain more recognition over time. Note: While an ISO standard is well received by big enterprises, it can pose a hindrance for smaller organizations due to its extensive implementation requirements.
Specification approach
The SPDX specification follows a monolithic approach of defining all required standard fields and identifiers for describing software packages and licenses.
CDX’s specifications are more flexible. They’re based on an extensible schema requiring only minimal information and allowing you to add other features later.
License identification
SPDX uses a standardized license list with short identifiers for common licenses.
CDX provides more detailed license information, including custom license names and texts.
Vulnerability mapping
SPDX doesn’t have built-in support linking library versions to known vulnerabilities.
CDX supports linking component versions to vulnerability databases and identifiers (e.g., CVE, CVSS, etc.)
Tooling and ecosystem
SPDX is a much more mature and popular format, and as such, it has a larger ecosystem of tools, libraries, and services for creating, parsing, and analyzing SBOMs. Every major security service provider supports SPDX, and software package managers commonly support SDPX license tags.
But again, the CDX ecosystem is growing rapidly due to both its backing by OWASP and its flexible extension approach.
If you’re looking for open source SBOM tools for either SPDX or CDX, check out this article.
Governance
SPDX is governed by the SPDX Workgroup within the Linux Foundation. Its teams meet online multiple times a month to discuss, for example, new versions or updates to the documentation
The CycloneDX Core Working Group governs CDX within the OWASP Foundation. Its teams meet online once a month.
Granularity
Both formats support definitions at the application level.
SPDX also allows you to define different licenses for multiple code snippets in a file. So, if you can’t add a new file for code that has its own license, SPDX can still capture it.
CDX's API support even allows a definition for each interaction the API provides. This is helpful if only one API endpoint has a vulnerability since you can avoid or work around it while still using the safe endpoints.
How does Wiz support SBOMs?
Wiz features an SBOM generator that supports both SPDX and CDX. It can generate SBOMs from your running infrastructure, so you know what software is running. With its agentless approach, you don’t have to install anything on your cloud resources to generate an SBOM from your installed software. This makes it a lightweight tool you can add anytime without having to worry about updates to your containers or virtual machines.
Furthermore, it supports Go, Java, Python, and NodeJS and can store the created SBOM files automatically on S3.
Summary
SPDX and CDX are capable SBOM formats, each with its own strengths and weaknesses. While SPDX is heavier than CDX, its bigger ecosystem and recognition by the ISO make it a good choice for enterprises that prefer a proven approach and have processes in place to work with such a comprehensive specification.
CDX might be a younger contender in the SBOM ecosystem, but its lightweight extension approach is easier for small teams to handle, especially those adopting SBOMs to track vulnerabilities. And if you want to include service APIs in your SBOMs, CDX is more straightforward to use.
Overall, either format is well suited to manage your software dependencies, and Wiz’s agentless SBOM generator supports both.
Gain complete visibility of your applications’ components, including packages, open-source libraries, and nested dependencies, without blind spots.
