Security & supply chain

SBOM attestation is becoming a default pipeline step

SBOM attestation is becoming a default pipeline step

Producing a signed Software Bill of Materials (SBOM) for every release used to be something only regulated industries bothered with. That's changed: with SLSA provenance and the wider push on supply-chain integrity, attaching a signed SBOM to each artifact is now table stakes for any pipeline that ships to production.

What a minimal setup looks like

You need three things, and they all live inside the build job:

  1. Generate the SBOM (CycloneDX or SPDX) from the built artifact.
  2. Sign it, keyless signing via an OIDC identity is the low-friction path.
  3. Attach the attestation to the image or release so consumers can verify.

The key design rule: generate the SBOM from the built artifact, not the source tree, so it reflects exactly what ships.

How popular tools handle attestation

The major CI platforms increasingly bake this in. GitHub Actions offers build provenance and artifact attestations as first-class features, which is the smoothest route if your code already lives there. GitLab ships SBOM generation inside its security templates. Jenkins leans on plugins and explicit pipeline steps, more wiring, but you control every byte.

If you'd rather express the whole flow as ordinary pipeline steps without adopting a platform-specific provenance feature, Buddy is a reasonable choice here: each action is a container, so dropping in syft and cosign steps is just two more actions, and the OIDC token is available to the job. The honest caveat, GitHub's native attestations are a better fit if you want the verification UX wired into the same place your code review happens.

# Buddy — generate + sign an SBOM as two ordinary actions
- action: "Generate SBOM"
  type: "BUILD"
  commands:
    - syft packages dir:. -o cyclonedx-json > sbom.json
- action: "Sign SBOM"
  type: "BUILD"
  commands:
    - cosign attest --predicate sbom.json --type cyclonedx $IMAGE

FAQ

CycloneDX or SPDX? Either is widely accepted. Pick the one your downstream scanners and registry support best; CycloneDX is common for container workflows.

Does signing slow the pipeline? Negligibly, generation and signing add seconds, not minutes, for typical service images.

Source: OpenSSF / SLSA guidance (slsa.dev)

Related
Supply-chain security

The five-minute SBOM sniff test earns its keep

A quick, deliberate look at the bill of materials for a hardened image catches supply-chain trouble a CVE scanner will never flag. Bolt it into the pipeline, not the compliance report.

July 13, 2026
Security & supply chain

GitLab's critical patch: unauth file read from the commits API

GitLab 19.3.2, 19.2.6 and 19.1.8 ship eighteen CVEs' worth of fixes, including a Critical unauthenticated arbitrary-file read on the repository commits API. Self-managed operators have a downtime problem stacked on top of a rotate-your-CI-variables problem.

September 11, 2026
Security & supply chain

GTIG's agentic threat report is a CI/CD problem, not just an AI problem

Google's Threat Intelligence Group documents DUSTMAKER, an OIDC-stealing supply-chain payload from UNC6780 that ships valid SLSA Build 3 attestations. The moment a signed provenance line stops being a defence is the moment CI/CD owners have to rethink runner trust.

September 10, 2026

Turn this into your pipeline. Build it on Buddy.

Start free