SBOM Basics: A Beginner's Guide

What is an SBOM?

Think of a Software Bill of Materials (SBOM) as a list of ingredients for a piece of software. Just like a recipe lists all the ingredients needed to bake a cake, an SBOM lists all the software components that make up an application. This helps producers, buyers, and operators understand what components are actually included in a product.

These components include open-source libraries, commercial off-the-shelf products, and even other pieces of your own software. The goal is to create a complete and accurate inventory of everything that has gone into your software product.

The U.S. National Telecommunications and Information Administration (NTIA) defines an SBOM as:

An SBOM is a formal, machine-readable inventory of software components and dependencies, information about those components, and their hierarchical relationships. These inventories should be comprehensive — or should explicitly state where they could not be.

An SBOM is a static file associated with a particular software release. It represents a snapshot of the software’s composition at a specific point in time. Each time a new version of the software is released, a new SBOM should be generated to reflect the updated composition.

What an SBOM is NOT

An SBOM is not a vulnerability report. It does not contain live security data.

Vulnerability information is dynamic — it changes constantly as new CVEs are published and existing ones are updated. An SBOM, by contrast, is a static snapshot of software ingredients at a specific release point.

SBOMs are usually stored in a machine-readable format such as JSON or XML. The following excerpt from a CycloneDX SBOM for Keycloak 10.0.2 shows what such a document can look like in practice:

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.2",
  "serialNumber": "urn:uuid:411dafd2-c29f-491a-97d7-e97de5bc2289",
  "version": 1,
  "metadata": {
    "timestamp": "2020-08-02T21:21:17Z",
    "component": {
      "type": "application",
      "group": "org.keycloak",
      "name": "keycloak-parent",
      "version": "10.0.2",
      "licenses": [{ "license": { "id": "Apache-2.0" } }],
      "purl": "pkg:maven/org.keycloak/[email protected]"
    }
  },
  "components": [
    {
      "type": "library",
      "group": "org.jboss.logging",
      "name": "jboss-logging",
      "version": "3.4.1.Final",
      "licenses": [{ "license": { "id": "Apache-2.0" } }],
      "purl": "pkg:maven/org.jboss.logging/[email protected]?type=jar"
    }
  ]
}

More examples of real-world SBOM documents, including different formats and use cases, can be found in the official CycloneDX bom-examples and SPDX examples repositories.

Why SBOMs Matter

SBOMs provide transparency into the software supply chain. They help organizations understand which components are included in a product, where those components came from, and how they may affect security, compliance, and maintenance activities.

One of the most important benefits of an SBOM is vulnerability response. When a new vulnerability is disclosed in a widely used library or framework, an SBOM makes it possible to quickly determine whether your software contains the affected component and in which versions. This can significantly reduce the time needed to assess exposure and prioritize remediation.

SBOMs also support license compliance. Many software products incorporate open-source and third-party components with different licensing terms. An SBOM helps teams identify those licenses early, document obligations accurately, and avoid surprises later in the release or procurement process.

In practice

An SBOM does not solve supply chain challenges by itself, but it gives teams the structured information they need to respond.

More information

What’s Inside an SBOM?

An SBOM contains structured information about a software product and the components it includes. The NTIA Minimum Elements report defines a baseline set of data fields that should be included so that SBOMs remain useful and interoperable across tools and organizations.

An SBOM is a structured file that contains key information about the software and its components. The NTIA has defined the following minimum elements that every SBOM should include:

Data Field	Description
Supplier Name	The name of the entity that creates, defines, and identifies components.
Component Name	The designation assigned to a unit of software by its original supplier.
Version	Identifier used by the supplier to specify a change in software from a previously identified version.
Other Unique Identifiers	Other identifiers used to identify a component, or that serve as a look-up key for relevant databases (e.g., CPE, PURL).
Dependency Relationship	Characterizing the relationship that an upstream component is included in the software.
Author of SBOM Data	The name of the entity that creates the SBOM data for this component.
Timestamp	Record of the date and time of the SBOM data assembly.

These fields form the foundation of an SBOM. Together, they make it possible to identify what a component is, who supplied it, which version is present, and how it relates to other components in the software. This is what allows automated systems to correlate SBOM entries with external sources such as vulnerability databases, license registries, and package repositories.

In real-world SBOMs, producers often include additional information beyond these minimum elements. Common examples include declared licenses, cryptographic hashes, external references, descriptions, and repository links. These extra fields are not always required for a minimal SBOM, but they are often valuable for security analysis, compliance workflows, and software transparency.

Minimum does not mean complete

The NTIA Minimum Elements define a practical baseline of what an SBOM should contain. However, many modern SBOMs include richer metadata to support broader use cases such as vulnerability management, provenance tracking, and compliance automation.

SBOM Formats

An SBOM is first and foremost a technical concept: a structured inventory of the software components contained in a product. The term SBOM itself does not describe one specific file format. Instead, it refers to the idea of documenting software composition in a way that can be shared, reviewed, and analyzed.

To make this concept practical, interoperable, and machine-readable, standardized formats are needed. Today, the two most important standards used to represent SBOMs are SPDX and CycloneDX. These standards define how component information, metadata, relationships, and other relevant details are encoded so that tools can generate, exchange, and process SBOMs automatically.

Concept vs. format

An SBOM is the concept of describing software components and their relationships. SPDX and CycloneDX are the standards that define how this information is represented in a machine-readable way.

SPDX

SPDX (Software Package Data Exchange) is an open standard from the Linux Foundation, standardized as ISO/IEC 5962:2021. Initially focused on license compliance, SPDX has expanded to cover security, provenance, and AI. Version 3.x introduced a modular profile architecture (Software, Security, Licensing, AI, Build, Dataset, and more) and shifted from a document-centric to an element-centric data model.

SPDX 2 supports several flat-file serializations, including tag-value, JSON, and YAML, while SPDX 3 moves away from flat files toward linked information, using a more graph-oriented model that is designed for richer and more flexible exchange, utilizing file formats like JSON-LD.

CycloneDX

CycloneDX is a lightweight BOM standard from the OWASP community, standardized as ECMA-424. It is designed with a strong focus on security and component analysis and provides SBOMs in JSON, XML, and Protocol Buffers.

Practical Usage of SBOMs

To use SBOMs in practice, it helps to think in terms of three simple roles: Producer, Distributor, and Consumer. These roles describe what actually needs to happen for SBOM technology to be useful: someone must create the SBOM, someone must make it available, and someone must use it.

The Producer is the party that creates the SBOM. In practice, this usually means introducing tooling that automatically generates an SBOM. The producer’s task is to ensure that the SBOM accurately reflects the released software and contains the component and metadata information needed by downstream users.

The Distributor is the party that provides the SBOM to others. This may be the software vendor, a package repository, a platform operator, or an internal team that ships software to another part of the organization. The distributor’s task is to publish or transfer the SBOM in a way that keeps it associated with the correct software artifact and makes it accessible to those who need it.

The Consumer is the party that reads and uses the SBOM. This may be a security team checking for vulnerable dependencies, a compliance team reviewing licenses, a customer evaluating supplied software, or an operations team documenting deployed components. The consumer’s task is to retrieve the SBOM, interpret its contents, and use it for a specific purpose such as risk analysis, auditing, or inventory management. To this end, appropriate tools are used to analyze the SBOM, enrich it with data, and provide analyses.

For more detail on each role, see the Producer, Distributor, and Consumer pages.

Types of SBOMs

The components that an SBOM describes depend heavily on the phase of the product lifecycle in which it is generated. An SBOM generated from source code can list managed dependencies, but it cannot capture dynamically linked components that are resolved only at runtime.

CISA and the German BSI have defined six different types of SBOMs:

Type	Description
Design	SBOM of an intended, planned software project with included components (some of which may not yet exist).
Source	Created directly from the development environment, source files, and included dependencies.
Build	Generated as part of the build process to create a releasable artifact from source files, dependencies, and build data.
Analyzed	Generated through analysis of artifacts (e.g., executables, containers) after the build, often using heuristics. Sometimes called a “3rd party” SBOM.
Deployed	Provides an inventory of software present on a system, potentially combining multiple SBOMs with configuration analysis.
Runtime	Generated by instrumenting a running system, capturing only components actually present and dynamically loaded.

Understanding these types is important because the scope shifts across phases. A Source SBOM is identical for every instance of a product, while a Runtime SBOM may differ for the same software running on different systems.

Both SPDX and CycloneDX allow producers to indicate the lifecycle phase in which the SBOM was generated.

SBOM Extensions and Related Artifacts

An SBOM statically describes which components a software product contains. However, it does not answer the question: is a known vulnerability actually exploitable in my environment? This is where extensions and related artifacts like Vulnerability Exploitability eXchange (VEX) come in. They extend the SBOM view by adding additional (dynamic) information and context.

Among the best-known extensions and artifacts are:

• VEX — Vulnerability Exploitability eXchange. It states whether a known vulnerability affects a product and whether it is exploitable in a specific context.
• VDR — Vulnerability Disclosure Report. It provides structured information about a vulnerability disclosure, including details about affected products and remediation guidance.
• Attestations and Provenance — Evidence about how an artifact was produced, built, signed, or derived, helping verify trust and origin.
• PURL — Package URL. A standardized identifier used to name and locate software packages across ecosystems.

More information

Related BOM Standards

SBOMs describe the components of a software product, but other kinds of Bill of Materials (BOMs) are used to describe different parts of the digital supply chain. These related standards extend the same basic idea of structured inventory into areas such as hardware, software-as-a-service, cryptography, and AI/ML systems.

Among the best-known related BOM standards are:

• HBOM — Hardware Bill of Materials. It describes the physical components, parts, and hardware dependencies that make up a device or system.
• SaaSBOM — Software-as-a-Service Bill of Materials. It describes the third-party services, dependencies, and software components used to deliver a SaaS product.
• AI/ML-BOM — Artificial Intelligence / Machine Learning Bill of Materials. It describes models, datasets, training components, and other artifacts used in AI or ML systems.
• CBOM — Cryptography Bill of Materials. It describes the cryptographic algorithms, libraries, certificates, keys, and related dependencies used in a product or system.

These types of bills of materials can either be viewed separately or combined in a single document to describe various properties. In fact, both SPDX and CycloneDX can be used for all of these bills of materials. Both standards support documenting various properties of a system and are not limited to software components. You can think of it this way: the bill of materials lists the various components of a system, and each component has a type—for example, software, cryptography, or hardware. Depending on the types included in the bill of materials, it is an SBOM, CBOM, HBOM, SaaSBOM, AI-BOM, or a combination of these. The term “xBOM” often comes up in this context. It refers to the concept of an “Extended or Everything Bill of Materials”—that is, a bill of materials that describes various aspects of a system.

More information