Automate SBOM generation and image signing in your CI/CD pipeline using Syft and Cosign. Secure your supply chain and reach SLSA Level 3. Full breakdown.
Why SBOMs and signed attestations matter
A software bill of materials (SBOM) is a machine-readable inventory of what went into an artifact: packages, versions, licenses, and dependency relationships. Without one, you cannot answer basic incident questions—whether a vulnerable library ships in a given image, which builds are affected, or when a component first entered the tree. Generating that inventory by hand does not scale; it has to be produced automatically from the same build that produces the binary or container image.
An SBOM alone is not enough. Attackers can swap an image or invent a fake inventory if nothing cryptographically binds the claim to the artifact. Signed attestations close that gap: a signature over a statement such as “this digests maps to this SBOM” or “this image was built by this pipeline under these controls.” Consumers then verify the signature against a trusted key or identity before they promote or deploy the artifact.
Generate SBOMs with Syft in CI
Syft scans container images, filesystems, and archives and emits SBOMs in common formats (for example SPDX or CycloneDX). Wire it into the job that builds the image so the inventory always matches what you ship. Scan the final image digest, not an intermediate layer or an unchecked-out source tree that may diverge from the published artifact.
Store the SBOM as a build artifact and attach it to the image (as an attestation or sidecar file your registry and policy tools can fetch). Fail the pipeline if generation fails or if the output is empty when you expected dependencies. Keep the format stable across teams so scanners, policy engines, and audit tooling can consume every release the same way.
Sign images and attestations with Cosign
Cosign signs container images and attaches signatures and attestations without forcing you to redesign your registry layout. After the image is pushed, sign the image digest and attach the SBOM as a signed attestation bound to that digest. Prefer keyless or identity-based signing backed by your CI’s workload identity when you can: keys sitting as long-lived secrets in the pipeline are a common weak point.
Verification belongs in the same path as promotion. Before a staging or production deploy, require a valid signature from an allowed identity and a present, matching SBOM attestation. Reject digests that lack either. That turns supply-chain checks into a gate, not a dashboard someone might ignore.
- Build the image and record its digest.
- Run Syft against that digest and publish the SBOM.
- Sign the image and attach the SBOM attestation with Cosign.
- Block deploy unless signature and attestation verify.
Path to SLSA Level 3
SLSA Level 3 centers on a hardened, isolated build service that produces provenance you can trust: the build ran in a controlled environment, the source and entry point are recorded, and the provenance is signed so consumers can verify it. Automating Syft and Cosign does not by itself complete Level 3, but it covers two pillars you need on that path—complete materials inventory and non-forgeable statements about what was built.
To move further, run builds in an ephemeral, policy-controlled environment (not a long-lived shared runner with broad credentials), generate signed provenance that links source revision to output digest, and verify that provenance at admission time alongside your image signature and SBOM. Treat the pipeline definition as code under review so build steps cannot be altered silently. Start with SBOM generation and Cosign signing on every image build; then tighten isolation and provenance until verification of signed build claims is mandatory before anything reaches production.