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

Pillar research says the AI coding agent sandbox leaks through trusted files

Pillar Security researchers demonstrated multiple sandbox-bypass techniques against AI coding agents, plus prompt-injection attacks hidden in READMEs, code comments and dependencies. OpenAI, Google and Cursor have patched several of the reported flaws.

July 23, 2026
Security & supply chain

Time-to-exploit went negative. Mandiant maps where AI helps the vulnerability queue, and where it fails silently.

Google Cloud's Mandiant team pins mean time-to-exploit at negative seven days and publishes a blueprint for aiming large language models at the vulnerability pipeline. The failure modes it lists are the ones that let the exploit through.

July 22, 2026

Turn this into your pipeline. Build it on Buddy.

Start free