AA-sec logo AA-sec
SBOM

How to Generate and Maintain Release-Specific SBOMs in CI/CD

A practical CI/CD workflow for generating release-specific SBOMs, validating the result, binding it to the shipped artifact, and retaining evidence for later vulnerability work.

AA-sec26 August 2026
  • release-specific SBOM CI/CD generation
  • generate SBOM in CI CD
  • SBOM CI pipeline
  • automatic SBOM generation
  • release SBOM pipeline
  • continuous SBOM management
Cover graphic showing a CI/CD pipeline generating and validating an SBOM linked to a specific software release artifact.

A useful SBOM CI/CD pipeline should generate a software bill of materials at a defined point in the build, validate that it describes the intended software, bind it to the exact release artifact, and retain enough context to reproduce that relationship later. The goal is not merely to produce bom.json on every run. It is to make sure that, months after release, a vulnerability team can identify which SBOM belonged to which shipped version and understand how that inventory was produced.

The Cyber Resilience Act (CRA) requires manufacturers to identify and document vulnerabilities and components, including by drawing up an SBOM in a commonly used, machine-readable format covering at least the product's top-level dependencies. The Regulation does not require manufacturers to use CI/CD to create that SBOM. Automating generation in the delivery pipeline is an engineering approach that helps keep the inventory aligned with changing releases and makes the generation evidence repeatable.

ENISA's 2026 SBOM adoption report describes organisations investing in SBOM generation and automation to integrate SBOMs into the software development lifecycle. The practical challenge is therefore no longer just whether a team can generate an SBOM, but whether the automated result stays connected to the product release it is supposed to describe.

Generate the SBOM where release identity becomes stable

The best generation point depends on what the SBOM is intended to represent.

A source-oriented SBOM can be useful early in development because package manifests and dependency resolution data are available before the final artifact exists. A build-generated SBOM can observe information available while dependencies are resolved and software is assembled. A post-build or analysed SBOM can inspect binaries, packages, containers or firmware after the build.

CycloneDX explicitly models lifecycle phases, and its authoritative guide describes several generation approaches, including build plugins, software-factory integration, software composition analysis and post-build analysis. SPDX likewise distinguishes SBOM types such as source, build and analysed SBOMs and provides a Build profile for describing build inputs, outputs and tools.

Those perspectives are not interchangeable. A source SBOM may contain dependencies that never reach the final image. A post-build scanner may discover bundled components that are not visible in a package manifest. For release evidence, define which perspective is authoritative for the product and document any additional SBOMs that supplement it.

A practical default for many software products is:

  • generate an SBOM during or immediately after the reproducible release build;
  • ensure the release artifact already has its final version or immutable identifier;
  • optionally run an independent post-build scan where the product form makes that useful; and
  • retain the generation perspective so consumers know what the inventory represents.

The important rule is consistency. If one release uses a source-tree inventory and the next uses an artefact scan without recording the change, a component diff may reflect a tooling change rather than a product change.

Treat the release artifact as the pipeline subject

Do not make the repository branch the primary identity of the SBOM. Branch names move, tags can be recreated in some workflows, and a commit can produce different artifacts when build inputs or environments differ.

The pipeline should identify the concrete subject that will be released. Depending on the product, capture:

  • product and variant;
  • release or version identifier;
  • artifact name and type;
  • immutable artifact digest where available;
  • source revision;
  • pipeline or build execution identifier;
  • build environment or builder identity where relevant;
  • SBOM format and specification version;
  • SBOM generator and version;
  • generation timestamp; and
  • lifecycle perspective such as source, build or analysed.

For a container, the image digest is often a stronger release binding than a mutable tag. For a firmware package, a cryptographic hash of the released image can provide the same role. For a signed package, keep the package identity and hash without treating the SBOM system as the signing system.

This relationship should survive outside the CI job. A later reviewer should not need access to an expired pipeline workspace to prove that product-4.8.2.cdx.json described the artifact that was actually approved for release.

Use a deterministic pipeline sequence

An SBOM pipeline is easier to audit when generation, validation and retention happen in a predictable order.

1. Resolve dependencies and build the release

Run the normal controlled build process first or reach the build stage where the intended dependency set is known. Avoid generating the final release SBOM from a developer workstation when the release itself is produced in a different environment.

Capture the identifiers needed to link later evidence to this run: source revision, build number, target platform, product version and expected artifact identity.

2. Generate the SBOM with a pinned tool version

Treat the generator as part of the evidence chain. Pin or otherwise control the version used for production SBOMs rather than silently accepting whatever version happens to be installed on a runner.

Generator upgrades can change package discovery, normalization, dependency graphs or output structure even when the product has not changed. When the tool version changes, make that visible in the release evidence and expect the first diff to require additional review.

Where practical, keep generation configuration in version control. That includes exclusions, package-manager settings, file-system scan boundaries and format options that materially affect the result.

3. Add stable subject and build metadata

After generation, confirm that the SBOM identifies the intended product or root component and not merely the repository or scanning directory.

CycloneDX BOM metadata can describe the target component, generation tools and lifecycle context. SPDX can represent an SBOM and, where the Build profile is used, relationships between a build and its inputs, outputs and tools.

You do not need to populate every optional field. The objective is to preserve enough machine-readable and external release metadata to answer: what was built, which SBOM describes it, and how was that SBOM generated?

4. Validate before publishing the SBOM

Schema or specification validation should be a mandatory first gate. A malformed document should not become release evidence.

Then add pipeline checks that are specific to the subject:

  • the root component or product identity matches the release;
  • the expected version is present;
  • component references are internally consistent;
  • required direct dependencies are represented where they are known;
  • no unresolved template values remain;
  • the generator reports success rather than partial failure;
  • the output is non-empty and machine-readable; and
  • any declared exclusions or incomplete coverage are retained.

This validation does not prove that every component has been discovered. It verifies that the generated artifact satisfies the team's declared pipeline contract. Separate SBOM quality reviews can go deeper into completeness, identity and dependency relationships.

5. Compute and retain the SBOM digest

Treat the generated SBOM as a release artifact in its own right.

Calculate a cryptographic digest after final normalization and validation. Retain that digest with the release record, together with the released software artifact digest. If the SBOM is later enriched or corrected, create a new version or replacement record instead of silently changing the file behind the original digest.

This matters during incident and vulnerability work because it distinguishes the inventory that existed at release time from a later reconstructed inventory.

6. Compare with the previous approved release

A pipeline does not need to fail because an SBOM changed. Software releases are expected to change.

Instead, compare the new inventory with the previous approved release and surface changes that deserve explanation:

  • components added or removed;
  • version changes;
  • unexpectedly large drops in component count;
  • dependency graph changes;
  • new unresolved identities;
  • changed generation perspective; and
  • changed generator or configuration.

The output of the comparison should be a review signal, not an automatic legal conclusion. A legitimate dependency update may create a large diff. A tiny release may unexpectedly replace a critical runtime. The pipeline can identify the change; engineering still decides what it means.

Separate SBOM generation from vulnerability decisions

Do not turn the SBOM generator into a vulnerability-conformity oracle.

An SBOM identifies components and relationships. Vulnerability tooling can use that data to find candidates associated with known vulnerabilities, but a match still needs product-context analysis. Component presence does not by itself prove exploitability, and absence from a weak or incomplete SBOM does not prove that a component is absent from the product.

A useful pipeline therefore separates three records:

  1. SBOM generation result — what components and relationships were observed.
  2. Vulnerability analysis result — which candidates were identified from that inventory.
  3. Engineering decision — whether a candidate affects the product, what action is required, and what evidence supports the conclusion.

This separation keeps regeneration predictable. Updating a vulnerability database should not require changing the historical SBOM for an already released artifact.

Define which failures block the release

A good CI/CD integration has explicit failure classes.

Hard-fail the pipeline when the SBOM process itself is unreliable, for example when:

  • generation fails;
  • the output cannot be parsed;
  • the document fails the required specification validation;
  • the release subject or version is wrong;
  • the expected output file is missing;
  • a required component data source could not be read; or
  • the SBOM cannot be tied to the artifact being released.

Use a review or exception path for findings that require judgement, such as:

  • a large but plausible dependency change;
  • a newly unsupported package ecosystem;
  • partial relationship coverage;
  • a generator upgrade that changes output;
  • a component with ambiguous identity; or
  • an accepted limitation in a platform-specific scan.

The exception record should state the affected release, reason, owner, decision and follow-up. Do not hide pipeline warnings merely to keep the release green.

Handle multi-artifact products deliberately

Many products do not have one artifact and one SBOM. Embedded products can contain firmware, operating-system images and separately updated applications, while other products may combine artifacts from several pipelines.

Choose the model explicitly:

  • create a release-level SBOM that composes the relevant subcomponents and preserves their relationships; or
  • retain several scoped SBOMs and link each one to the exact product component or artifact it describes.

Do not merge inventories merely to obtain one file if that destroys release scope. The pipeline should make the composition rule explicit and repeatable.

Retain enough evidence outside the CI runner

CI logs are useful, but they are often ephemeral and difficult to use as long-term product evidence.

For each approved release, retain at least:

  • the final SBOM file;
  • SBOM digest;
  • product, variant and release identity;
  • released artifact digest or other immutable identifier;
  • source revision and build or pipeline identifier;
  • generator name and version;
  • declared SBOM format and specification version;
  • generation configuration or a stable reference to it;
  • validation result;
  • material diff or exception decisions; and
  • the time and lifecycle stage at which the SBOM was generated.

The CRA's technical documentation requirements include the SBOM within the description of vulnerability-handling processes. Keeping the generation record connected to release evidence makes that documentation easier to reconstruct and helps vulnerability teams avoid analysing the wrong product version later.

BSI currently publishes TR-03183 Part 2 as dedicated technical guidance for SBOMs. Treat such guidance as implementation support; the legal requirement comes from the CRA itself.

Do not confuse internal retention with public distribution

The CRA requires manufacturers to draw up the SBOM, but it does not generally require publishing the complete SBOM publicly. Annex II addresses where users should be told how to access the SBOM if the manufacturer decides to make it available to the user.

That distinction matters for pipeline design. Generation and retention can be mandatory internal release steps while external distribution remains a separate policy decision.

If an SBOM is distributed to customers or partners, publish the approved release-specific artifact rather than generating a fresh file from the current source tree. The distributed document should still correspond to the product version it claims to describe.

Common CI/CD failure patterns

Several implementation shortcuts weaken an otherwise automated process:

  • generating only on the default branch, while releases may come from another controlled ref;
  • generating before dependency resolution, so the file describes intended rather than built dependencies;
  • using an unpinned generator version, which mixes tooling changes with product changes;
  • naming the SBOM only by product version, making rebuilt artifacts difficult to distinguish;
  • overwriting the previous SBOM and losing the inventory that existed at release time;
  • coupling vulnerability findings directly into the historical inventory; and
  • keeping the file without the build context needed to identify its artifact.

These are engineering failures rather than separate CRA violations by definition. They weaken the manufacturer's ability to maintain accurate component records and supporting lifecycle evidence.

A compact reference workflow

For a typical release pipeline, the operating sequence can be reduced to eight controls:

  1. Build or identify the exact release artifact.
  2. Generate the SBOM with a controlled tool and configuration.
  3. Attach product, release, lifecycle and build identity.
  4. Validate the format and expected subject.
  5. Calculate the SBOM digest and compare material changes with the previous release.
  6. Run vulnerability analysis as a separate downstream process.
  7. Store the SBOM, digests, validation result and exceptions with the release evidence.
  8. Publish or exchange the approved SBOM only through the organisation's defined distribution policy.

This workflow is not prescribed by the CRA. It is a practical way to keep a machine-readable component inventory reproducible and release-specific as software changes.

A release-specific SBOM becomes much more useful when its component data, validation evidence and later vulnerability decisions remain connected to the exact release. AA-sec is designed around traceability between SBOM and component data, vulnerability work, security evidence and lifecycle decisions, and the MVP scope includes direct REST API integration for CI/CD evidence ingestion. It complements CI/CD rather than replacing build or signing systems, and it does not determine CRA conformity.

Key takeaway

Automating SBOM generation is valuable only if the automation preserves identity and context. Generate at a defined lifecycle stage, bind the result to the actual release artifact, validate the pipeline contract, retain the SBOM and its digest, and keep vulnerability decisions separate from the inventory itself.

The durable question is not "Did CI generate an SBOM?" It is "Can we prove which SBOM described this exact release, how it was generated, what limitations were known, and which later security decisions relied on it?" A pipeline designed to answer that question produces evidence that remains useful long after the build job has disappeared.

Official sources