SBOM formats explained: Guide for enterprises

What are the elements of an SBOM?

CISA recommends that SBOMs consist of several elements. At a minimum, include the following baseline attributes:

• Author name. List the name of the person or organization that created the SBOM. Include as many people as necessary, and when possible, include contact information.
• Timestamp. Include the date and time that the SBOM was created.
• Type of SBOM. This optional attribute explains helps users understand why and how the SBOM was created.
• Primary component. Also known as the root of dependencies, the primary component is the main element of the SBOM, for example, a product or application.

Also include the following component data about each primary component and its dependencies:

• Component name.
• Component version.
• Supplier name.
• Additional unique identifiers.
• Cryptographic hash.
• Dependency relationship.
• License.
• Copyright notice.
• Known CVEs (optional).
• Last updated or patched (optional).

Vendor contractual obligations and missing or conflicting data might prevent teams from including all these data points. When this happens, write "no assertion" or "no value."

Common SBOM formats

The three standard SBOM formats are CycloneDX, SPDX and SWID tags. Let's examine each option in more detail.

CycloneDX

OWASP's open source CycloneDX SBOM format aims to reduce cyber-risk and improve the security of source code development. OWASP designed CycloneDX to be more lightweight than other formats, which is ideal for agile organizations.

CycloneDX breaks out the software's components, services, dependencies and compositions into a readable list. Security teams can add important data and details about the software, including vulnerabilities, manufacturing and deployment info, and other contextual information.

The format works with XML, JSON and protocol buffer data formats, and suits organizations focused on identifying and tracking vulnerabilities.

CycloneDX supports the ability to create the following:

• SaaSBOMs. SaaSBOMs document the different components and services of SaaS applications. CycloneDX covers HTTP/HTTPS, REST, GraphQL and MQTT protocols.
• Hardware BOMs. HBOMs inventory IoT devices and industrial control systems.
• Cryptographic BOMs. CBOMs include details of cryptographic assets used within software.
• Machine learning BOMs. ML-BOMs inventory the models and data sets used for ML and AI integrated into software.
• Operations BOMs. OBOMs break down runtime environments and their hardware, systems, firmware, libraries and more.
• Vulnerability disclosure reports. CycloneDX documents and publishes reports on known vulnerabilities and how to remediate them for components within an SBOM.
• Vulnerability Exploitability eXchange. Security teams can create a VEX, which documents the details, context and remediation efforts of any component vulnerabilities found.

SPDX

Created by the Linux Foundation, the open source SPDX became the only internationally recognized SBOM standard in 2021, known as ISO/IEC 5962:2021. Large organizations often select SPDX when they need to manage the licenses of the software components in use, as well as mitigate vulnerabilities.

SPDX inventories application components, license and copyright info, and security references. To improve security, teams can use common global reference systems, such as Common Platform Enumeration, Software Heritage persistent ID or Package URL, to connect software artifacts. SPDX also supports a variety of file formats, including SPDX, JSON, YAML, RDF and XLS.

SPDX comprises the following three parts:

• SPDX specification.
• SPDX licensing scheme.
• SPDX tools and libraries.

The latter are built by the community alongside commercial vendor tools. Some open source SPDX tools include the following:

• Build. Creates plugins or extensions that provide build file metadata and source files.
• Audit Tool. Analyzes modules of the source code using various auditing techniques.
• License Diff. Enables security teams to document the differences between source code modules.
• Merge. Brings all source code modules into one cohesive format during software development.

SWID Tags

NIST's SWID tagging differs from CycloneDX and SPDX because it technically is not a full-fledged SBOM format. SWID tags -- which contain standardized information about software -- help software and security teams track installed software to remain compliant with licensing agreements and up to date with patches. They do not aggregate information on all software, as CycloneDX and SPDX do. Rather, SWID tag producers -- software and platform developers -- create tags to help SWID tag consumers -- organizations using that software -- gain transparency into the components of their products.

Security teams can integrate SWID tags into automated scanning tools for security use cases, including vulnerability scanning. NIST is also currently adding SWID tag data to the National Vulnerability Database. SWID tag data has already been added to the Security Content Automation Protocol (SCAP) version 1.3.

Alongside tracking installed software on managed devices, SWID tags help teams do the following:

• Determine if software components used in the application development process are compliant with organizational security policies.
• Apply software patches and updates.
• Confirm a valid configuration process is in place.
• Find, deprecate and replace outdated legacy software with newer versions.
• Detect changes made to software installation media.
• Halt unauthorized software installation.

CycloneDX vs. SPDX vs. SWID tags compared

Each SBOM format helps secu

While all three tools help software and security teams create and maintain an SBOM, it is important to be aware of their differences.

How to choose an SBOM format

SBOMs are required for many industries, such as vendors that sell to federal agencies, certain healthcare and medical device manufacturers, and financial institutions. Even if an organization isn't mandated to have an SBOM, it should create one to reap the security benefits.

That brings up the question of which SBOM format to use. Consider the following when evaluating CycloneDX, SPDX and SWID tags:

• The goal of the SBOM. If your team needs it for vulnerability management, CycloneDX is ideal. If you need it to follow licensing agreements, SPDX is best.
• Integration needs. Make sure the SBOM format chosen works with your team's software development tools. For example, the format should integrate with continuous integration/continuous delivery pipelines and support product lifecycle management, ERP and quality management system software.
• Scalability requirements. Ensure the SBOM format can quickly adapt to new project demands, complexities and scale based on your organization's requirements.
• SBOM format training. The GUI must be easy enough for the software development team to use quickly, effectively and efficiently. Teams should be able to glean information and data from a single dashboard.
• Automation needs. Use automation to ensure SBOMs are quickly updated whenever software components are patched or removed.
• Compliance need. Verify that the SBOM format can produce compliance reports on an as-needed basis, for example, to maintain compliance with the tenets and provisions of data privacy laws.
• Community support. The three SBOM formats listed in this article are open source, so healthy community support is key to keeping them relevant, updated and included in future SBOM creation tools.

Ravi Das is a cybersecurity consultant and business specialist who specializes in penetration testing and vulnerability management content.