Understanding SBOM Standards: A Look at CycloneDX, SPDX, and SWID

Modern applications are no longer giant monoliths, they are a collection of micro services, open-source components, and third-party tools. But this makes it very difficult to actually understand the insides of our applications, particularly when you consider that our open-source dependencies also have open-source dependencies!

The Software Bill of Materials (SBOM) plays a key role here. SBOMs provide a detailed inventory of all software components. This doesn't just help us understand our software, but it also allows us to identify risks and meet our compliance and governance requirements.

For SBOMs to work well, they need to be standardized and easily shared across various systems and tools. Here’s where SBOM standards become vital.

Understanding SBOM Standards

SBOM standards establish a common format for creating and sharing SBOM data. They offer a unified language, ensuring consistent communication across different organizations and tools.

Standardization is necessary because SBOMs can be lengthy and packed with details about components, versions, licenses, and dependencies. Without a standard format, interpreting and using SBOM data becomes challenging for different entities.

Currently, three main SBOM standards are popular in the industry:

1. CycloneDX: A lightweight standard with a focus on security, supporting various BOM types, including software, hardware, and services.
2. SPDX (Software Package Data Exchange): The only SBOM standard recognized by ISO, known for its comprehensive approach to component data and origins in software licensing.
3. SWID (Software Identification) Tags: Focused on software identification, aiding in tracking installed software for asset management.

Each standard has specific strengths and use cases, which we will discuss further.

CycloneDX at a Glance

• Built specifically for security use cases (e.g., vulnerability tracking, VEX support, component hashing).
• Natively supports VEX (Vulnerability Exploitability eXchange) and dependencies trees.
• Compatible with modern DevSecOps pipelines and tools like OWASP Dependency-Check, Anchore, GitHub Advanced Security.
• Easier to integrate in CI/CD environments (lightweight, JSON-friendly).

CycloneDX stands out for its efficiency and robust security features. Its design allows quick integration, making it ideal for teams valuing agility and security. CycloneDX covers software, hardware, and service-related materials, making it versatile for different technology environments.

CycloneDX supports multiple data formats including XML, JSON, and protobuf, ensuring compatibility with various tools. Under the OWASP umbrella, CycloneDX evolves continuously to address current security challenges in software supply chains.

Example CycloneDX formatting‍


{  
  "bomFormat": "CycloneDX",
  "specVersion": "1.5",
  "version": 1,
  "components": [
    {
      "type": "library",
      "name": "example-lib",
      "version": "1.0.0",
      "purl": "pkg:npm/example-lib@1.0.0",
      "licenses": [{ "license": { "id": "MIT" } }]
    }
  ]
}

Exploring SPDX

• Aimed at legal teams and IP due diligence (strong licensing metadata model).
• Extensive license expression language (SPDX license list).
• Standardized under ISO/IEC 5962:2021.
• Used in major efforts like OpenChain, ORT, and Tern.

SPDX is globally acknowledged as the sole SBOM standard with ISO accreditation, enhancing its credibility. Initially crafted for software licensing, SPDX has expanded to meet broader software transparency needs.

SPDX supports multiple data formats like tag/value, JSON, XML, YAML, and RDF, integrating smoothly with various tools and platforms. It provides in-depth insights into software components, documenting files and code snippets for detailed compliance and security tracking.

Example SPDX formatting‍


SPDXVersion: SPDX-2.3
DataLicense: CC0-1.0
SPDXID: SPDXRef-DOCUMENT
DocumentName: example-sbom
DocumentNamespace: http://spdx.org/spdxdocs/example-sbom
Creator: Tool: SPDX-Tools
Created: 2025-05-08T12:00:00Z

PackageName: example-lib
SPDXID: SPDXRef-Package-example-lib
PackageVersion: 1.0.0Package
DownloadLocation: NOASSERTION
PackageLicenseConcluded: MIT
PackageLicenseDeclared: MIT
PackageChecksum: SHA256: abcdef1234567890abcdef1234567890abcdef1234569ui

Understanding SWID Tags

• Targeted at enterprise software inventory management.
• Standardized as ISO/IEC 19770-2 — very government/military focused.
• Used in FedRAMP, NIST 800-171, and related compliance frameworks.

SWID Tags focus on clear software product delineation. Unlike comprehensive SBOMs, SWID Tags identify individual software packages, which are crucial for accurate inventory management.

In asset management, SWID Tags offer a standardized method to track software installations, ensuring organizations maintain an accurate software landscape. This helps in compliance and optimizing asset management strategies.

SWID Tags integrate with frameworks like SCAP and TCG standards, enhancing their role in security and compliance.

Example SWID formatting‍


<SoftwareIdentity xmlns="http://standards.iso.org/iso/19770/-2/2015/schema.xsd"                     name="example-lib"
version="1.0.0"
tagId="example-lib@1.0.0"
patch="false"
                  
</SoftwareIdentity>

Comparing SBOM Standards

To differentiate CycloneDX, SPDX, and SWID Tags, start with their features. CycloneDX caters to flexible BOM management in dynamic security environments. SPDX excels in compliance tracking, while SWID Tags focus on precise software identification. Here’s a quick comparison:

CycloneDX’s structure addresses the need for transparency. SPDX provides detailed documentation and data integrity for compliance oversight.

Each standard suits specific needs. CycloneDX fits teams prioritizing rapid, secure development. SPDX appeals to organizations focused on compliance. SWID Tags enhance asset management by ensuring precise tracking.

Conversion tools between these formats are essential for maintaining interoperability. Advanced solutions allow organizations to benefit from each standard’s strengths, tailoring strategies to meet specific requirements.

Choosing the Right SBOM Standard

It's not enough to generate an SBOM in just one format. Different stakeholders—be they internal auditors, government agencies, or enterprise customers—may require the SBOM in a specific format to ingest it into their existing tooling or workflows. For instance:

• A federal contract may require SPDX, while a security vendor conducting a risk assessment may prefer CycloneDX.
• Some CI/CD systems may support only certain SBOM formats for policy enforcement or automated scanning.

Tooling Matters: Choose One That Supports Multiple Formats

Given this variability, you must choose a tool that can generate SBOMs in multiple formats from the same source artifacts. Tools like Aikido Security simplify this process by automatically generating SBOMs during your build pipeline or security scans and exporting them in formats like CycloneDX, SPDX, and others as needed.

This multi-format capability ensures you remain compliant across diverse requirements, without duplicating work or introducing errors from manual conversions.

‍