SBOM formats explained: SPDX, CycloneDX, and SWID

A Software Bill of Materials (SBOM) is a list of the components that make up a piece of software, with enough metadata to identify each one. Three formats are standard: SPDX, CycloneDX, and SWID. They overlap in purpose and differ in shape, history, and the ecosystems where they are most used.

This post is a plain comparison of the three formats — what each does well, where each is used, and how to pick one. No format is "the" right answer; your choice depends on what consumes the SBOM.

Why SBOMs

An SBOM answers two basic questions about a binary or container: what's inside, and where did each piece come from? At minimum, an entry contains a name, a version, a license, and an identifier (purl, CPE, or hash). With that you can correlate what you ship against vulnerability advisories.

Regulators have begun requiring SBOMs for software supplied to government buyers. Industry adoption beyond regulation is uneven; for most teams, SBOMs are a defensive tool — produce one, store it, query it when an advisory drops.

SPDX

SPDX (Software Package Data Exchange) was created by the Linux Foundation in 2010, originally focused on license compliance. It became an ISO standard (ISO/IEC 5962) in 2021.

Format. SPDX 3.x is structured around documents that describe packages and the relationships between them. Earlier SPDX 2.x is widely deployed and uses a simpler tag-value or JSON shape.

Strengths. Mature license metadata: the SPDX License List is the canonical reference for short license identifiers (MIT, Apache-2.0, BSD-3-Clause, etc.) used across nearly every other tool. Strong adoption in enterprise compliance workflows.

Weaknesses. SPDX 3.x is more complex than the simpler SPDX 2.x; tooling adoption of 3.x is still catching up. The format is less focused on vulnerability correlation than CycloneDX.

When to choose it. When license compliance is the primary consumer. When you need ISO-standard format for procurement. When your tooling stack is centered on SPDX (notably Linux distribution packaging).

CycloneDX

CycloneDX is an OWASP project. Version 1.0 shipped in 2017, oriented from the start at security analysis rather than license compliance.

Format. JSON or XML. Structured around components, services, dependencies, and vulnerabilities. Supports BOM-Link to reference external documents.

Strengths. Native support for vulnerability data (VEX statements). Lightweight components-list shape that maps cleanly to most package managers' outputs. Well-supported by application security tools and CI generators.

Weaknesses. License metadata is less rigorous than SPDX historically, though gaps have been closing.

When to choose it. When the SBOM will be consumed by vulnerability scanners or AppSec tools. When you want the simplest format that fits both software and services. When your CI pipeline already produces CycloneDX (most language ecosystems have first-class generators).

SWID

SWID (Software Identification Tag) is an ISO/IEC standard (19770-2) that predates SPDX and CycloneDX. It originated in the asset-management and inventory world rather than open-source supply chain.

Format. XML. Each SWID tag is metadata about a single installed software product on an endpoint.

Strengths. Designed for endpoint inventory: "what is installed on this machine?" Well-supported in enterprise asset-management tools. Includes integrity tags for tamper-evidence.

Weaknesses. Not built around the package-manager-and-dependency model that npm, PyPI, Maven, etc. use. Treats software as a single product per machine; less natural for component-level dependency listings.

When to choose it. When the SBOM consumer is asset management or compliance reporting at the endpoint level. When you are required by procurement to deliver SWID tags.

How they relate

The three formats are not mutually exclusive. Many tools can convert between SPDX and CycloneDX. SWID lives somewhat apart and is mostly a separate workflow.

A pragmatic stack:

• Generate CycloneDX in CI for each build (most ecosystems have first-class generators: cyclonedx-bom for npm, cyclonedx-py for Python, cyclonedx-maven-plugin for Java). Use this for vulnerability correlation.
• Generate SPDX for compliance handoff if your buyer requires it. Convert from CycloneDX if needed.
• Add SWID tags if you ship installable software products to enterprises that require them.

Identifiers across formats

All three formats can include identifiers, but the canonical ones are:

• purl (package URL): a string scheme that uniquely identifies a package across ecosystems, e.g. pkg:npm/lodash@4.17.21. Both CycloneDX and SPDX support purl natively.
• CPE (Common Platform Enumeration): NIST's identifier scheme used in CVE data. Useful for joining SBOM components against the National Vulnerability Database.
• SHA-256 hash: the canonical content-addressed identifier. Always include it.

If you produce one SBOM and want it to be useful across consumers, include all three identifiers per component.

Takeaway

Pick CycloneDX for security workflows, SPDX for compliance and license-heavy consumers, SWID only when explicitly required. Generate at every build, store with the build artifact, and verify on consumption. The format matters less than producing one consistently and tying each line item to a verifiable identifier.