SBOM Standard Formats: What They Are, How to Choose & Examples

Today’s software is complex. Each modern software application typically includes a large number of open source and commercial components coming from a wide range of sources. According to the 2024 Open Source Security and Risk Analysis report, on average, 97% of codebases contain open source. That’s where an SBOM, or software bill of materials, comes in.

For those new to this topic, be sure to learn the basics of SBOMs and their role in cybersecurity first. Put simply, however, an SBOM is a structured list of components, modules, and libraries that are included in a given piece of software. Think of them like a list of ingredients that evolves throughout the software development lifecycle as you add new code or components. 

To ensure the security of the software you create, it is imperative that you maintain a comprehensive list of the components in each release of a software application in order to identify vulnerable and outdated code. You can also use an SBOM to monitor the security of each application post-deployment by identifying the potential impact of new security vulnerabilities on your user-facing applications.

Explore how Google leveraged 100M+ SBOMs to protect their software supply chain.

Register Now

Are SBOMs Required?

As of April 2025, SBOMs are not universally required in the U.S. or the EU. However, they are required in specific cases in the U.S. per Executive Order 14028 and they will be required for all digital products sold in the EU as of December 2027.

In the U.S., the Executive Order to Improve the Nationa’s Cybersecurity (2021) directs federal agencies to “publish minimum SBOM standards” and define criteria regarding “providing a purchaser a software bill of materials (SBOM) directly or publishing to a public website.” This means all software suppliers that sell to U.S. federal government agencies need to provide SBOMs for the software they deliver. Since the EO’s initial publication, these standards have had a ripple effect as companies in other industries began to mirror the federal requirements in their own software procurement efforts.

In the EU, SBOMs were introduced as a mandatory requirement under the 2024 Cybersecurity Resilience Act (EU CRA). The act requires manufacturers selling hardware and software products with digital elements in the EU to create and maintain a Software Bill of Materials (SBOM) in machine-readable format. The requirement will go into effect as of December 2027.

What is an SBOM Standard? 

To facilitate this widespread adoption of SBOMs, several SBOM formats have been developed to provide a unified structure for both generating SBOMs internally and sharing them upstream with end-users and customers. An SBOM standard is a schema designed to provide a common format for describing the composition of software in a structured way that is consumable by other tools, such as vulnerability scanners. CycloneDX and Software Product Data Exchange (SPDX) are the most commonly used standards.

Standard SBOM Formats

CycloneDX

CycloneDX is a lightweight, machine-readable SBOM standard useful for application security contexts and supply chain component analysis. CycloneDX is an open source project that originated in the OWASP community and is guided by a Core Team that provides strategic direction and maintenance of the standard.

The full CycloneDX specification is available online at GitHub or the CycloneDX site.

SPDX

The Software Package Data Exchange (SPDX) is a machine-readable international open standard (ISO/IEC 5962:2021) format for communicating the components, licenses, and copyrights associated with a software package. The SPDX standard is developed by a grassroots open source project hosted by the Linux Foundation. It draws representatives from vendors, foundations, and system integrators.

A tech team and legal team do the work behind the project. SPDX holds a scheduled monthly status call about their progress.

The full SPDX specification and archives are available on the SPDX site. There’s also an SPDX GitHub repo available.

Other SBOM Formats

SWID tags (short for Software Identification tags) were previously considered a third standard, primarily used by the U.S. federal government. Introduced in 2009 as an XML-based format, SWID tags have since lost traction and are rarely used in comparison to SPDX and CycloneDC.

Choosing an SBOM format: SPDX vs CycloneDX 

There are many opinions on which format – SPDX or CycloneDX – is the best format for specific use cases. Some years ago, there were arguments for using one format if your focus was open source dependencies, or the other if your focus was licensing. 

Recently, we have seen the industry move away from specific focuses for SBOM and converge on SBOM formats containing complete and accurate dependency and license details. The two formats differ in how they are constructed, but the data contained within them is functionally the same for many SBOM use cases. For example, at Anchore we support both SPDX and CycloneDX because there is equally strong demand for the two formats.

SBOM Quality and Minimum Elements

There is a definition of the minimum elements that should be included in an SBOM. Below is a table with the minimum data fields and descriptions:

The NTIA’s SBOM minimum elements document is long and is several years old now. The world of SBOMs has changed dramatically in recent years, and like any technology, the more use it gets, the more it changes to solve real problems.

Rather than speaking of minimum elements, the conversation can switch to SBOM quality, but without an adequate definition of quality. The SPDX and CycloneDX standards are working to ensure future versions of the standards define minimum expectations in a way that ensures every SBOM created has the data needed to be useful to the recipient.

If you are the recipient of an SBOM today, there isn’t an easy way to verify if the document contains the data you need to conduct analysis. By using an SBOM management solution it is possible to ingest the documents then view the results to understand if the data needed exists. If it does not, changes can be requested from the supplier of the SBOM to ensure the SBOM received is correct.

SBOM Examples to Help You Get Started

There are a number of ways to create an SBOM, everything from manually creating the document to running a scanner. An SBOM scanner is a tool that analyzes software packages to identify and document all the open-source and proprietary components, libraries, and dependencies used. The scanner route is much easier than trying to construct a properly formed SBOM by hand. A scanner also gives you the ability to output both SPDX and CycloneDX formats and conduct deep inspections of your software.

To help you get started, we will use the Syft open source SBOM generator. Syft is very easy to use and can output both SPDX and CycloneDX formats.

SBOM Example in SPDX Format

Syft supports SPDX Tag-Value (spdx-tag-value) and SPDX JSON (spdx-json). For SPDX JSON, simply add the -o spdx-json argument. For example, run:

syft alpine:latest -o spdx-json

You’ll see there is a lot more data than the table view allows! You should see something resembling:

{
  "spdxVersion": "SPDX-2.3",
  "dataLicense": "CC0-1.0",
  "SPDXID": "SPDXRef-DOCUMENT",
  "name": "alpine",
  "...": "...",
  "creationInfo": {
    "licenseListVersion": "3.25",
    "creators": [
      "Organization: Anchore, Inc",
      "Tool: syft-1.19.0"
    ],
    "created": "2025-01-27T15:29:58Z"
  },
  "packages": [
    {
      "name": "alpine-baselayout",
      "SPDXID": "SPDXRef-Package-apk-alpine-baselayout-421bc6506abee7e4",
      "versionInfo": "3.6.8-r1",
      "supplier": "Person: Natanael Copa ([email protected])",
      "...": "...",
      "sourceInfo": "acquired package info from APK DB: /lib/apk/db/installed",
      "licenseConcluded": "NOASSERTION",
      "licenseDeclared": "GPL-2.0-only",
      "copyrightText": "NOASSERTION",
      "description": "Alpine base dir structure and init scripts",
      "externalRefs": [
        {
          "referenceCategory": "SECURITY",
          "referenceType": "cpe23Type",
          "referenceLocator": "cpe:2.3:a:alpine-baselayout:alpine-baselayout:3.6.8-r1:*:*:*:*:*:*:*"
        },
        {
          "referenceCategory": "PACKAGE-MANAGER",
          "referenceType": "purl",
          "referenceLocator": "pkg:apk/alpine/[email protected]?arch=aarch64&distro=alpine-3.21.2"
        }
      ]
    },
  ]
}

Not only does this format contain the package names, but also Package URLs, license information, and a host of additional metadata, such as, the location of associated files Syft identified within the package.

SBOM Example in CycloneDX Format

Similarly, if you need to generate an SBOM in CycloneDX format use a CycloneDX format option. Syft supports CycloneDX XML (cyclonedx-xml) and JSON (cyclonedx-json). For CycloneDX XML:

syft <source> -o cyclonedx-xml

To run this against the same latest Alpine image, run:

syft alpine:latest -o cyclonedx-xml

And you should see a result resembling this:

<?xml version="1.0" encoding="UTF-8"?>
<bom xmlns="http://cyclonedx.org/schema/bom/1.6" serialNumber="urn:uuid:ffc83bc6-8806-4331-b515-2d1962589034" version="1">
  <metadata>
    <timestamp>2025-01-27T10:49:00-05:00</timestamp>
    <tools>
      <components>
        <component type="application">
          <author>anchore</author>
          <name>syft</name>
          <version>1.19.0</version>
        </component>
      </components>
    </tools>
    <component bom-ref="327aecd176f7b31f" type="container">
      <name>alpine</name>
      <version>sha256:47badde288cf303fe43766ba3c0be01df313b84ad91480c1f21b7e907a7f2337</version>
    </component>
  </metadata>
  <components>
    <component bom-ref="pkg:apk/alpine/[email protected]?arch=aarch64&distro=alpine-3.21.2&package-id=421bc6506abee7e4" type="library">
      <publisher>Natanael Copa <ncopa@alpinelinux.org></publisher>
      <name>alpine-baselayout</name>
      <version>3.6.8-r1</version>
      <description>Alpine base dir structure and init scripts</description>
      <licenses>
        <license>
          <id>GPL-2.0-only</id>
        </license>
      </licenses>
      <cpe>cpe:2.3:a:alpine-baselayout:alpine-baselayout:3.6.8-r1:*:*:*:*:*:*:*</cpe>
      <purl>pkg:apk/alpine/[email protected]?arch=aarch64&distro=alpine-3.21.2</purl>
      <externalReferences>
        <reference type="distribution">
          <url>https://git.alpinelinux.org/cgit/aports/tree/main/alpine-baselayout</url>
        </reference>
      </externalReferences>
      <properties>
        <property name="syft:package:foundBy">apk-db-cataloger</property>
        <property name="syft:package:type">apk</property>
        <property name="syft:package:metadataType">apk-db-entry</property>
        <property name="syft:cpe23">cpe:2.3:a:alpine-baselayout:alpine_baselayout:3.6.8-r1:*:*:*:*:*:*:*</property>
        ...
      </properties>
    </component>
  
  ...

  </components>
</bom>

There is a lot of additional information in the SBOM, but this example shows how easy it can be to generate an SBOM and what the output will look like. See the whole process for How to Generate an SBOM with Free Open Source Tools.

What’s next: Generating and Managing SBOMs at Scale

As SBOMs rapidly gain acceptance, industry leaders have begun to develop approaches for creating, managing, and using SBOMs. While individual development or application teams may store SBOMs in a repository alongside their code artifacts, security teams must maintain a centralized repository of SBOMs across all applications and development teams.

When new vulnerabilities or security incidents arise, security teams and CISOs need the ability to quickly query the SBOMs of all of their software and instantly assess the impact instead of frantically scrambling to get individual assessments from each development team or having to waste valuable time finding and rescanning all of their applications from scratch. In addition, meeting regulatory requirements or compliance standards requires a centralized repository for reporting and other compliance activities.

Anchore Enterprise makes it easy for teams to manage SBOMs for increased security and quicker incident response. The platform provides a comprehensive set of SBOM management capabilities that enable teams to collect, store, analyze, automate, and use SBOMs across the application and software development lifecycles. 

Over the course of just a few short years, we have seen the role of SBOMs transition from a “nice to have” to a “need to have” for both development and security teams who have been forced to recognize in a post-Solarwinds world that the software they build is part of a bigger chain that goes beyond the confines of their containers. The use of SBOMs will continue to expand and become the foundational element in securing and managing software supply chains.