SBOM Standard Formats: Guide

SBOM (Software Bill of Materials) standards provide a consistent way to describe the components and dependencies within software, improving software supply chain security and transparency. Popular standards include CycloneDX, SPDX, and SWID Tags, each offering unique strengths for different needs. 

Here’s a quick look at the key SBOM standards:

CycloneDX:

• A lightweight, machine-readable standard focused on security and supply chain transparency. 
• Designed for application security contexts and component analysis within the software supply chain. 
• Supports various BOM types, including software, hardware, and services. 
• Emphasizes automation in SBOM generation and updates, allowing for agile responses to changes and vulnerabilities. 
• Originates from the OWASP (Open Web Application Security Project) community. 

SPDX (Software Package Data Exchange):

• Offers a more monolithic approach compared to CycloneDX’s extension-based design.
• The only SBOM standard recognized by ISO, providing comprehensive data on software components and origins. 
• Known for its thorough approach to software licensing information. 

What is an SBOM Standard? And what should SBOM standards include?

A Software Bill of Materials (SBOM) is a structured inventory of the components, libraries, packages, and modules, within a software application. But an SBOM on its own is only as useful as the standard that defines its format, structure, and completeness. That’s where SBOM standards come in.

An SBOM standard provides the rules and schema that determine:

• How component data is structured
• Which metadata is required or optional
• How relationships and dependencies are captured
• What formats are supported for sharing (e.g., JSON, XML, YAML)
• How trust, authenticity, and traceability can be maintained

Standards ensure that SBOMs are not just machine-readable but interoperable, meaning tools, vendors, and stakeholders can reliably parse, analyze, and act on them.

A well-defined SBOM standard should include:

• Component identifiers: Such as name, version, supplier, and unique IDs (e.g., PURLs, CPEs)
• Licensing information: Declared or discovered license for each component
• Dependency relationships: Direct and transitive relationships between components
• Hashes and integrity checks: For validating content integrity
• Timestamps: To track when the SBOM or components were generated
• Vulnerability and risk metadata (optional in some standards): For linking known issues to components

While different SBOM standards (like SPDX, CycloneDX, and SWID) handle these elements in their own way, these building blocks are the foundation of a complete and usable SBOM.

Software package data exchange (SPDX)

SPDX is an open standard for software bill of materials (SBOM) that identifies and catalogs components, licenses, copyrights, security references, and other metadata relating to software. Primarily designed to improve license compliance, it is also used to improve software supply-chain transparency and security. SPDX is authored by the community-driven SPDX Project under the auspices of the Linux Foundation. SPDX uses a standardized, machine-readable format that makes it consistent across different companies and industries. This reduces the need to reformat information, makes it easier to share, and consequently improves compliance and security efficiency. It is arguably the largest, most heavyweight SBOM format, and it’s the only one of the three main formats that has an ISO (International Organization for Standardization) accreditation. 

Who is it for?  SPDX is commonly used by large, complex organizations such as  Intel and Microsoft. Users with a preference for Linux inevitably gravitate towards SPDX, as do those that build software or operate enterprise software. More and more organizations are implementing SBDX, especially those that increasingly use open source projects and create commercial software.

Strengths and weaknesses. This format is good for providing a big picture of your software supply chain, components, and dependencies, which allows for a multiplicity of annotations and the most detail. That’s because SPDX identifies the software package, the package level, the file-level licensing and copyright data, and also shows the file creator, as well as when and how it was created. Its size and capacity make it a particularly flexible option, and it’s meant to be an all-inclusive format.

See how you can generate an SBOM report in SPDX here.

CycloneDX (CDX)

Created by the Open Worldwide Application Security Project (OWASP), CycloneDX is very similar to SPDX, albeit lighter. It is described as a full-stack bill of materials standard that provides advanced supply chain capabilities for cyber risk reduction. The specification supports:

• SBOM
• Software-as-a-Service Bill of Materials (SaaSBOM)
• Hardware Bill of Materials (HBOM)
• Operations Bill of Materials (OBOM)
• Vulnerability Disclosure Reports (VDR)
• Vulnerability Exploitability eXchange (VEX)

The CycloneDX project provides standards in XML, JSON, and protocol buffers, as well as a large collection of official and community-supported tools that create or interoperate with the standard. Strategic direction of the specification is managed by the CycloneDX Core Working Group and is supported by the global information security community.

Who is it for? CycloneDX is often preferred by nimbler organizations and by teams that use open source heavily.

Strengths and weaknesses. The lighter-weight nature of CycloneDX tends to make it more agile. It includes fewer details, which makes it simpler to use and perhaps more user-friendly than SPDX, although it’s also less inclusive.

Software identification tags (SWID) 

Established by the U.S. National Institute of Standards and Technology (NIST), SWID is an industry standard used by different commercial software publishers. According to NIST, SWID tags provide a transparent way for organizations to track the software installed on their managed devices. SWID tag files contain descriptive information about a specific release of a software product. SWID uses the following four types of tags: 

1. Primary: Identifies and describes a software product installed on a computing device. 

2. Patch: Identifies and describes an installed patch that has made incremental changes to a software product installed on a computing device. 

3. Corpus: Identifies and describes an installable software product in its pre-installation state. Used to represent metadata about an installation package or installer for a software product, a software update, or a patch. 

4. Supplemental: Allows additional information to be associated with any SWID tag, to ensure that primary and patch Tags provided by a software provider are not modified by software management tools, while allowing these tools to provide their own software metadata.

Who is it for? Organizations that want a quick, easy-to-use, and simple inventory of its software components and dependencies may prefer to use SWID, providing they understand that this format’s capabilities are much more limited than those of SPDX and Cyclone DX. Nevertheless, a number of standards bodies, including the Trusted Computing Group (TCG) and the Internet Engineering Task Force (IETF) use SWID Tags in their standards.

Strengths and weaknesses. If your aim is simply to create an inventory and catalog components and dependencies, SWID offers the easiest-to-use option. However, its use is limited to this. SWID focuses on being an inventory and isn’t as inclusive as the others. It doesn’t provide details such as vulnerability information, annotations, or license information, so it doesn’t solve as many issues as the other formats.

If you want to use an effective SBOM, you’re recommended to stick to one of the three main formats or a combination of them. While there are numerous other specifications out there, they aren’t standardized, so their use and influence are negligible. For a comprehensive list, consult the NTIA’s Survey of Existing SBOM Formats and Standards report. 

What About VEX? The Essential SBOM Companion

VEX, or Vulnerability Exploitability eXchange, isn’t technically an SBOM standard—but it plays an increasingly critical role in making SBOMs actionable. While an SBOM tells you what components are in your software, VEX tells you whether the known vulnerabilities in those components actually matter in your specific context.

Without VEX, security teams are left chasing every CVE listed in an SBOM, even if the vulnerable code is unreachable, disabled, or unused. This leads to noise, wasted effort, and slow remediation cycles. VEX changes that by letting software producers or trusted third parties declare whether a vulnerability is exploitable in the way a component is implemented.

A VEX document typically includes vulnerability identifiers, exploitability status, and a justification. For example, a component might be marked as “not affected” because the vulnerable function isn’t invoked, or “under investigation” if the vendor is still validating exposure. These declarations help downstream consumers prioritize the vulnerabilities that pose real risk.

While VEX can be delivered in multiple formats, it’s most often paired with CycloneDX or SPDX SBOMs, and supported by tools that enrich vulnerability data with runtime context or policy-based logic. In a modern AppSec workflow, SBOM and VEX are two halves of the same picture: one shows what’s there, the other shows what matters.

Why so many formats? 

SBOM development and adoption is not yet fully mature, which means that further standardization will happen as SBOM use becomes even more widespread.

For Generation X-ers — those of us of a certain vintage — the current situation brings to mind the video format war of the 1980s between Betamax and VHS video-cassette formats, and the high-definition optical disc format war of the early 2000s, between HD DVD and Blu-ray disc. The differentiators that drove VHS and Blu-ray to victory weren’t technical. Rather, cost, adoption, ease of use, availability of content to users, and sharing capabilities were the deciding factors.  I anticipate a similar dynamic will take place with SBOM formats. As governments increasingly introduce guidance that requires SBOMs, and more open source software components are used from an expanding volume of sources, SBOM use will increase and users’ demand for standardization into one format will amplify and gather momentum. Watch this space.

Predicting the winner

We can confidently say that SBOMs are going to play an important part in the process of developing and selling applications and software. Each of the main formats will serve an SBOM’s purpose. The one you choose depends on how granular you want and need to be, or perhaps how detailed the recipient of your SBOM requires you to be. That could vary depending on whether this party is a government body, a potential buyer in an M&A situation, or more simply a prospect or customer. Today most Software Composition Security (SCA) tools support both Cyclone DX and SPDX.

If I were to bet on a format that wins out, I’d choose Cyclone DX for a couple of reasons: 

• It combines more detail than SWID and enables you to retain vulnerability information, annotations, or license information.
• It provides you with an ease of use that beats SPDX. 

If you’re looking to choose an SBOM format, then that’s my recommendation. Most importantly for your business, is to put an effective SBOM in place because as you progress, it will become essential and unignorable.