Skip to main content

Software Bill of Materials (SBOM)

An SBOM is like a “nutrition label” for software: a machine-readable inventory of the components, versions, and dependency relationships that make up a product (firmware, OS image, application, container, etc.). It enables faster security response, stronger supply-chain transparency, and more reliable compliance workflows.

What is an SBOM​

A Software Bill of Materials (SBOM) is a formal record describing the components that are used to build and deliver a software product and how those components relate to each other in the supply chain and dependency graph.

In U.S. Executive Order (EO) 14028 context, an SBOM is described as a formal record containing details and supply-chain relationships of components used to build software—often compared to a food ingredient list.

Why you need an SBOM​

1) Faster, more accurate vulnerability impact assessment​

When a supply-chain incident happens (e.g., widely used libraries affected by a CVE), the hard part is often not “knowing a vulnerability exists” but determining whether your shipped product actually contains the vulnerable component, where it is used, and which version is included. SBOMs make this traceable and automatable.

2) Supply-chain transparency and traceability​

Modern products combine large amounts of open source and third-party software. SBOMs provide structured evidence of what you shipped, improving auditability and supporting incident response and downstream sharing.

3) Increasingly a standard procurement and delivery requirement​

Many organizations and government frameworks are moving toward SBOM expectations as part of secure software supply-chain practices—especially in machine-readable, standardized formats.

4) License (IP) compliance at scale​

A major part of compliance risk is simply knowing which licenses are included and whether obligations are met. Standards like SPDX are designed for consistent exchange of license and related metadata, which helps systematize compliance.

What information an SBOM typically contains​

A commonly referenced baseline is the NTIA “minimum elements,” which cover key fields such as:

  • Supplier
  • Component name
  • Version
  • Other unique identifiers (e.g., PURL/CPE/SWID…)
  • Dependency relationships
  • SBOM author / creator
  • Timestamp
note

SBOM value depends heavily on being machine-processable. A human-readable list (or a PDF screenshot) is much harder to use for automated vulnerability and license workflows.

Common formats: SPDX / CycloneDX​

SPDX​

  • SPDX is an open standard for exchanging SBOM and software metadata, and it is also an ISO/IEC 5962 international standard.
  • It has strong coverage for license and provenance-related metadata.

CycloneDX​

  • CycloneDX is an OWASP-driven BOM standard (ECMA-424) focused on reducing supply-chain risk and supporting security use cases, including extensions for vulnerability exchange artifacts.

SBOM in Embedded & Yocto​

Embedded products (kernel, rootfs, firmware, applications, and third-party blobs) often have long lifecycles and costly update paths. That makes it especially important to generate SBOMs at build time and store them together with release artifacts.

A minimal practical flow (Build → Store → Share → Use)​

Yocto / OpenEmbedded: create-spdx for SPDX SBOM output​

Yocto documentation explains that the OpenEmbedded build system can generate SBOMs (SPDX) via the create-spdx class, and it is inherited at the distro level by default (and can be removed if needed).

A common approach is to enable (or confirm) it globally:

# conf/local.conf or conf/distro/*.conf (depending on your project conventions)
INHERIT += "create-spdx"

An SBOM should not be a one-time artifact. Any change in recipes, patches, layers, configurations, or versions should trigger SBOM regeneration and tight linkage to the corresponding release build (version, commit hash, build ID, timestamp).

SBOM + Vulnerability Management: SBOM + VEX​

An SBOM tells you what you have shipped, but it does not automatically mean you are exploitable by a given CVE. Exploitability depends on build options, enabled features, runtime configuration, environment, and whether a fix/backport is already applied.

That is why SBOMs are often paired with VEX (Vulnerability Exploitability eXchange):

  • VEX is a way to communicate the impact/status of a vulnerability for a specific product (e.g., not affected, affected, fixed, under investigation).
  • Joint guidance explicitly calls out that VEX can be used alongside SBOMs to improve usefulness and prioritization.

References​