2.2 SBOM Lifecycle

Figure 1 depicts the conceptual perspective of the SBOM lifecycle aligned with the key principles of SBOM. The lifecycle begins with the software build and SBOM generation based on the necessary sources of information, progresses to the SBOM validation to assess the quality of the generated SBOM, followed by cryptographic signing to protect its integrity and authenticity, secure storage, operational consumption and continuous maintenance and updates.

Figure 1 - SBOM Lifecycle

The integration of SBOM generation and consumption into CI/CD pipelines is increasingly adopted and recognised as one of the best practises to achieve completeness, accuracy and trustworthiness. Automation enables organisations to generate, validate, update and consume up-to-date SBOMs. The findings of the SBOM Adoption State of Play 2026 reflect this, as 41 % of the organisations reported that they aim to fully automate SBOM generation for each release/build . However, automation is still a work in progress after the built stage as only 26 % of respondents believe that their organisations will fully automate SBOM updates across the product support period and almost 23 % believe that their organisations will partially automate this process.

While the previous section presented the conceptual perspective of the SBOM lifecycle, this

section presents the technical implementation of SBOM as part of a CI/CD pipeline . The

architectural diagram in Figure 2 aligned with the defined SBOM lifecycle phases depicts the integration of SBOM into the SDLC and the automation of each phase.

Each phase includes the key elements and processes to be considered successful along with basic failure points. This should not be interpreted as an exhaustive list of steps and aspects to consider when generating and consuming SBOMs but rather as an example of how SBOM integration and automation could be implemented.

The process begins with the source code build which produces the sources of information and then triggers the generation of SBOM. The SBOM generators attempt to identify the software components, extract relevant metadata, analyse dependencies, and produce machine-readable SBOMs in a standardized format (e.g., SPDX or CycloneDX). The generator collects, correlates, and structures metadata from the software build process and associated repositories.

Upon the successful generation of the SBOM, the validation process is triggered to assess if the SBOM is syntactically correct, conforms to the selected SBOM specification and contains the required metadata before triggering the next process. It is essential to also validate the component identifiers during this process.

Once validated, the SBOM is cryptographically signed to ensure authenticity and integrity before being stored in a repository or registry, to be consumed by downstream security tools.

The SBOM maintenance and update phase depicts the continuous process of keeping the SBOM up-to-date and synchronised with the current version of the software. Indicative automatic triggers are included to reflect the need to re-generate SBOMs and follow the lifecycle phases.

Finally, indicative security controls and trust mechanisms are depicted to protect the integrity, authenticity, and availability of SBOMs throughout the pipeline, enabling organisations to produce reliable SBOMs that can be consumed across development, security, operations, procurement and compliance teams.

Figure 2 - SBOM Architectural Diagram

Integration and automation are only possible when supported by the necessary tool stack. Based on the SBOM Adoption State of Play 2026, 33% of the organisations rely on open-source tools, thus Table 4 identifies open-source tools that could be integrated into a CI/CD pipeline to support the end-to-end SBOM lifecycle for both CycloneDX and SPDX formats. The tools are categorised based on the SBOM lifecycle phases and should not be considered as an exhaustive, but rather than an indicative list to support the purpose of this document.

The following table demonstrates that while some tools are format-agnostic and can support both SBOM formats, certain stages like SBOM generation, schema validation, and/or consumption require format-specific tooling.

scorecard

(eBAY)

spdx-maven-plugin,

spdx/tools-python,

spdx/tools-java,

spdx/tools-golang,

yocto (enabled by

default in poky),

linux (make spdx),

zephyr (west spdx),

kubernetes-sigs/bom,

GitHub SBOM,

Microsoft sbom-tool

(.NET),

Syft,

Trivy,

ORT,

SBOMit

Table 4 - Open-source SBOM Tool Stack

The fragmentation of SBOM formats poses a significant challenge to the implementation and tooling landscape. Tooling exists for seamless conversion between the formats, such as OpenSSF's (15) Protobom.