Skip to content

Software Bill of Materials (SBOM)

Introduction

A Software Bill of Materials (SBOM) is a machine-readable inventory of the software components included in a build. It helps product teams understand what is in a release, track dependencies, support vulnerability review, and maintain evidence for internal cybersecurity workflows. The Cyber Resilience Act (CRA) requires manufacturers of products with digital elements to include an SBOM in the technical documentation.

This page explains the general approach to building and analyzing an SBOM.

Example of an SBOM

Scenario

Assume you are building an application called my-application. This application needs to read and process XML configuration files. Instead of implementing XML parsing yourself, you rely on an existing open-source library: libxml2.

Using the Yocto Project libxml2 recipe as the basis, libxml2 depends on:

  • zlib
  • libiconv
  • Standard C libraries
  • python3 as an optional feature-related dependency in the recipe context

This creates a dependency chain, where your application indirectly depends on multiple lower-level components.

In this example, python3 is shown as an optional dependency to reflect that some recipe features can pull it in, while its own dependency tree is intentionally not expanded in the illustration.

Dependency Illustration

The following diagram illustrates how dependencies relate to each other. This is not an SBOM, but a simplified view to help understand what is happening:

graph TD
    A[my-application] --> B[libxml2]
    B --> C[zlib]
    B --> D[libiconv]
    B --> E[glibc]
    D --> E
    C --> E
    B -. optional .-> F[python3]
    F -. dependency tree omitted .-> G[...]

Example SBOM

The following is a simplified example of what an SBOM could look like for the dependency illustration above. It is intentionally short and human-readable. An automatically generated SBOM typically contains more fields, such as checksums, component identifiers such as CPE or PURL, file-level information, build metadata, and detailed license information.

sbomFormat: SPDX-like example
sbomVersion: 1.0
creationInfo:
  created: 2026-04-13T00:00:00Z
  creator: Variscite documentation example

package:
  name: my-application
  version: 1.0.0
  supplier: Example Vendor
  licenseDeclared: Proprietary
  dependsOn:
    - [email protected]

components:
  - name: libxml2
    version: 2.12.10
    supplier: GNOME Project
    licenseDeclared: MIT
    dependsOn:
      - [email protected]
      - [email protected]
      - [email protected]
    optionalDependsOn:
      - [email protected]

  - name: zlib
    version: 1.3.1
    supplier: zlib Project
    licenseDeclared: Zlib
    dependsOn:
      - [email protected]

  - name: libiconv
    version: 1.17
    supplier: GNU Project
    licenseDeclared: LGPL-2.1-or-later
    dependsOn:
      - [email protected]

  - name: glibc
    version: 2.39
    supplier: GNU Project
    licenseDeclared: LGPL-2.1-or-later
    dependsOn: []

  - name: python3
    version: 3.12.2
    supplier: Python Software Foundation
    licenseDeclared: PSF-2.0
    notes: Optional dependency shown without its full transitive dependency tree in this example.

This example shows several important SBOM characteristics:

  • my-application is the top-level product component.
  • libxml2 is a direct dependency of the application.
  • zlib, libiconv, and glibc appear as transitive dependencies.
  • python3 is represented as an optional dependency.
  • Dependency relationships are listed explicitly, making it easier to trace where each component comes from.

SBOM Generation

Generation of an SBOM is usually an automated process integrated into the software build or release workflow. The goal is to produce a complete inventory of all software components that are part of a product.

Two main approaches are commonly used:

  • Generation from build metadata (during the build process)
  • Generation via image analysis (scanning a finished artifact)

Both approaches have clear advantages:

  • Build metadata provides highly accurate and structured information directly from the build system.
  • Image analysis reflects the actual shipped software, including late modifications.
  • Both approaches can be automated and integrated into CI/CD pipelines.

Yocto SBOM Generation

In Yocto-based systems, SBOMs can be generated automatically as part of the build process using the available build metadata. This results in a highly accurate inventory of all components included in the image or individual packages.

Implementation details may vary between Yocto release branches. The following link shows how to create an SBOM for DART-MX95 on Yocto.

Yocto SBOM Generation

Debian SBOM Generation

For Debian-based systems, SBOM generation relies on package metadata and tooling available in the Debian ecosystem. This allows generation of an inventory based on installed packages and their relationships.

There is no single standardized way to create a Debian-based image. The exact build process varies by hardware platform and Debian version. As a result, some software components may be added outside the Debian package management system and will not be captured by these tools. See Limitations during SBOM generation for additional details.

Example pages:

Android SBOM Generation

Android provides mechanisms to generate software inventories, but the exact workflow depends on the Android platform version and build configuration.

Example pages:

Zephyr SBOM Generation

For Zephyr-based systems, SBOM generation depends on how firmware components and dependencies are defined and built.

The Zephyr project page provides some documentation on how to generate an SBOM with Zephyr.

Limitations during SBOM Generation

SBOM generation is usually automated. However, you should consider several limitations.

For SBOM generation based on metadata:

  • Metadata-based SBOM generation can be highly accurate, but it cannot cover packages or files installed outside the default build process.
  • SBOM data can only be as accurate as the metadata it uses. If a package is installed as raw binary data or firmware from a previous build process, the SBOM may not list its origin.
  • Metadata-based SBOM generation might not include packages installed through non-system package installation processes, such as PyPI for Python packages or npm for JavaScript.

For SBOM generation based on image analysis:

  • Image analysis often does not have access to the full set of metadata, such as patch level, version information, and build configuration.
  • Image analysis can occasionally produce false positives or incomplete identifications.

For SBOM generation in general:

  • Docker images, Flatpak packages, and compressed archives can contain many source components, and the SBOM might not list each component individually.

From SBOM Generation to Product Integration

Generating an SBOM is only one part of the process. The SBOM should be tied to the product release that it describes and stored with the related release artifacts.

For customer products, the exact integration process depends on the product release workflow, security process, and customer deliverable requirements. Variscite provides SBOM generation guidance for supported software releases, but customers are responsible for deciding how SBOM data is reviewed, archived, and shared as part of their own product lifecycle.

A typical integration workflow includes these steps:

  1. Define which build output represents your real production software.
  2. Generate an SBOM for that build, not only for a reference image.
  3. Store the SBOM together with the release artifacts and version information.
  4. Use the SBOM as an input to vulnerability review and maintenance planning.
  5. Regenerate the SBOM whenever the product software changes.