Living SBOMs in the Pipeline: Generating, Signing and Attesting Provenance

An SBOM on its own proves nothing. The gap between “here is our bill of materials” and “here is proof this bill of materials describes the artefact you are actually running” is where most supply-chain assurance quietly falls apart.

A software bill of materials is a list. Lists can be edited, stale, generated against the wrong branch, or produced by a well-meaning developer on a laptop and emailed as a spreadsheet. If a customer, an auditor or a market surveillance authority receives an SBOM as a file, they have a claim and nothing more. They cannot tell whether it matches the binary in production, when it was produced, or which pipeline produced it. This is a jurisdiction-neutral engineering problem, and it has a jurisdiction-neutral engineering answer: generate the SBOM at build time, sign it, and attach signed provenance describing how the artefact was made. Do that and the SBOM stops being an assertion and becomes evidence someone downstream can check without trusting you.

Why a bare SBOM proves nothing

The failure mode I see most often is the paper SBOM: a document generated once, checked into a wiki, and treated as the answer. It drifts from the shipping artefact within a release or two, and nobody notices because nothing binds the document to the binary. I have written before about why static paper SBOMs fail in production, and the core defect is always the same: there is no cryptographic link between the list of components and the thing running.

What a downstream consumer actually wants to answer is narrower than “is this software good.” It is: does this SBOM describe this exact artefact, was it produced by a build I have some reason to trust, and can I verify both without phoning the vendor. Answering that needs three things to be true at once — the SBOM is generated from the built artefact, not written by hand; the artefact and its SBOM are signed; and there is a provenance record stating which builder, source and parameters produced them.

Three artefacts, one build

The build produces one primary artefact — usually a container image — and then two pieces of evidence attached to it by digest.

• The SBOM. Generated by a tool that reads the built image, not the source tree, so it reflects what shipped. CycloneDX and SPDX are the two common machine-readable formats; pick one and be consistent.
• The signature. A cryptographic signature over the artefact’s digest, and a matching signature over the SBOM, so any tampering after the build breaks verification.
• The provenance attestation. A signed statement, in the in-toto attestation format the SLSA framework uses, recording the builder identity, the source commit and the build parameters. This is what turns “trust me” into “here is how it was made.”

The unifying discipline is that everything binds to the artefact’s immutable digest, never to a mutable tag. A tag can be re-pointed at a different image five minutes after you signed it; a digest cannot. Sign by tag and you have signed a label, not a thing.

The pipeline step

Here is the shape of a CI step that builds an image, generates a CycloneDX SBOM from it, signs the image, attests the SBOM, and attaches an SLSA provenance attestation. It uses Sigstore’s cosign in keyless mode, where the signing identity comes from the CI system’s OIDC token and the signature is recorded in a public transparency log rather than resting on a long-lived private key you have to guard.

#!/usr/bin/env bash
# CI step: build, generate a CycloneDX SBOM, sign the image and SBOM,
# and attach an SLSA provenance attestation. Keyless signing via CI OIDC.
set -euo pipefail

IMAGE="registry.example.com/app"
TAG="${GIT_SHA:?commit sha required}"

# 1. Build and push, then resolve the immutable digest — never sign a tag
docker build -t "${IMAGE}:${TAG}" .
docker push "${IMAGE}:${TAG}"
DIGEST="$(docker buildx imagetools inspect "${IMAGE}:${TAG}" 
  --format '{{json .Manifest.Digest}}' | tr -d '"')"
REF="${IMAGE}@${DIGEST}"

# 2. Generate a CycloneDX SBOM FROM the built image, not the source tree
syft "${REF}" -o cyclonedx-json=sbom.cdx.json

# 3. Sign the image itself (identity comes from the pipeline's OIDC token)
cosign sign --yes "${REF}"

# 4. Attest the SBOM against the same digest
cosign attest --yes --type cyclonedx 
  --predicate sbom.cdx.json "${REF}"

# 5. Attach SLSA build provenance describing how the artefact was produced.
#    provenance.json is emitted by the build backend (buildx SLSA output
#    or a SLSA generator), not written by hand.
cosign attest --yes --type slsaprovenance 
  --predicate provenance.json "${REF}"

Nothing here is exotic. The point is that the SBOM and the provenance are outputs of the same build that produced the artefact, signed in the same run, bound to the same digest. That is what makes them a living record generated from the pipeline rather than documentation maintained on the side and slowly diverging from reality.

The key-management and verification model

Signing raises the obvious question: whose key, and where does it live. There are two models, and the decision is a governance decision, not merely a tooling preference.

The keyless model above holds no long-lived signing key at all. The build authenticates to Sigstore with a short-lived OIDC token, receives a short-lived certificate bound to that identity, signs, and the signature is logged to a public transparency log. There is no private key to leak, rotate or store in a secret manager. The cost is that your trust anchor becomes the CI identity and the public log, so your verification policy has to pin the exact workflow identity you expect — otherwise anyone able to run a build can produce a signature that verifies.

The key-based model uses a signing key you hold, ideally in a KMS or hardware security module so the private material never leaves it. This is more familiar to firms with existing key-management governance, and it keeps the trust anchor inside your own boundary. The cost is exactly that key: it must be rotated, access-controlled and audited, and a compromise is a serious incident. Neither model is universally correct. Regulated firms with mature HSM practice often prefer key-based; teams optimising for no key to lose lean keyless. What matters is that the verification side pins identity either way, because a signature nobody checks the signer of is theatre.

Verification is where the value is realised. A downstream consumer runs a verify step in their own admission pipeline that confirms the signature, checks it against the expected identity, and validates the provenance predicate before the artefact is allowed to run. That is the moment your supply-chain claims about dependencies you did not choose become something the consumer can enforce rather than hope for.

What the CRA actually asks for

The EU Cyber Resilience Act entered into force on 10 December 2024. Its vulnerability and incident reporting obligations begin to apply from 11 September 2026, and the main body of obligations becomes applicable from 11 December 2027. Within that, the Act requires manufacturers of products with digital elements to draw up an SBOM in a commonly used, machine-readable format covering at least the top-level dependencies, as part of the technical documentation.

Read the base text carefully before over-building. The CRA obliges you to produce and maintain the SBOM and hold it in your technical file for a market surveillance authority; it does not, in the core text, oblige you to publish it to every customer. The specifics of format and depth are being settled through implementing acts and guidance, so verify the current requirement rather than assuming the maximalist reading. But the direction is settled: an SBOM is becoming a regulatory artefact, and a regulator asking for evidence will not be satisfied by a document with no proof of origin.

Which is the whole argument. Whether the driver is the CRA, a customer’s procurement questionnaire or your own incident response, the SBOM you can defend is the one the pipeline signed, not the one someone typed. Build it so that anyone who doubts you can check for themselves — because sooner or later, someone will.