Supply Chain Security in CI: SBOMs, SLSA, and Sigstore

Software supply chain attacks target the build pipeline, not just the code. Defending against them requires visibility into dependencies, trusted build provenance, and artifact signing. SBOMs, SLSA, and Sigstore form a practical trio that you can implement in CI without a massive security budget.

This post shows a minimal pipeline that generates SBOMs with Syft, produces SLSA provenance, and signs artifacts with cosign.

Context

Problem: Build pipelines often ship artifacts without provenance or integrity guarantees. Approach: Add SBOMs, provenance, and signing as standard CI steps. Outcome: Auditable builds and stronger release integrity.

SBOMs with Syft

An SBOM lists the components inside your build artifact. Syft can scan container images or local directories and produce CycloneDX or SPDX output.

syft dir:. -o cyclonedx-json > sbom.json

In CI, store the SBOM as a build artifact so you can trace dependencies later. Use it to answer “is this vulnerable package in my build?” quickly.

SLSA provenance

SLSA (Supply chain Levels for Software Artifacts) defines how to record build provenance. You want to capture which commit, which build system, and which dependencies produced the artifact. Many CI systems now support provenance generation.

If you use GitHub Actions, you can enable provenance by adding --provenance when building with docker buildx, or by using the SLSA generator action. The resulting provenance document should be stored alongside the artifact.

Sign artifacts with Sigstore

Sigstore makes signing and verification practical by using OIDC and transparency logs. Cosign is the CLI tool for signing container images or blobs.

cosign sign --key cosign.key myregistry.local/app:1.0.0

You can also sign the SBOM itself, which lets you verify that it has not been altered.

cosign sign-blob --key cosign.key sbom.json

CI pipeline example

Here is a simple GitHub Actions snippet that builds an image, generates an SBOM, and signs both:

name: supply-chain
on: [push]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Build image
        run: docker build -t myregistry.local/app:$ .
      - name: Generate SBOM
        run: syft dir:. -o cyclonedx-json > sbom.json
      - name: Sign image
        run: cosign sign --key cosign.key myregistry.local/app:$
      - name: Sign SBOM
        run: cosign sign-blob --key cosign.key sbom.json

For production, use keyless signing with OIDC and store the signatures in a transparency log. In a lab, a local key is fine.

SBOM consumption and vulnerability scanning

Generating an SBOM is only the first step. Feed it into a vulnerability scanner to identify known CVEs in your dependencies. Tools like Grype can read CycloneDX and SPDX directly. This gives you a consistent way to scan without relying on the runtime environment.

grype sbom:sbom.json

Store the scan results alongside the SBOM so you can track remediation over time.

Build isolation and hermetic builds

SLSA emphasizes build integrity. Use isolated build environments and pin dependencies. In CI, build in a clean container and avoid using shared caches unless they are verified. If you can, use a lockfile and a deterministic build process so the same source produces the same artifact.

This makes provenance meaningful. If your build is non-deterministic, the provenance document tells you less because the artifact may vary run to run.

Attestation and policy enforcement

Attestations are only useful if you verify them. Add a policy step in your deployment pipeline that checks for a valid signature and a trusted provenance predicate. Sigstore policies can enforce that the build came from a specific repository and workflow identity.

In a lab, you can simulate this by verifying the signer and checking that the provenance references the expected commit hash.

Key management and transparency logs

If you use key-based signing, protect the private key like any other secret. Store it in a secure vault or hardware token. Rotate keys periodically and track which artifacts were signed with which key.

With keyless signing, Sigstore uses OIDC identities and a transparency log. This removes direct key management but introduces identity trust. Ensure your CI identity is locked down and only allowed to run trusted workflows. The transparency log provides a public record of signatures, which helps detect abuse.

Dependency pinning and policy as code

Supply chain hardening is not just about signing. Use lockfiles and pin dependency versions so you can reproduce builds and audit changes. Avoid floating tags in container base images and verify base image signatures.

Policy as code tools can enforce these rules. For example, deny builds that use unpinned dependencies or unsigned base images. Even in a lab, these policies teach discipline and highlight how small misconfigurations lead to risk.

Artifact repository hygiene

Store signed artifacts in a trusted registry and restrict who can push. Enable content trust or signature verification on pull so deployments only use verified artifacts. If you mirror public images, sign the mirror and treat it as the only allowed source in CI.

In a lab, set your Kubernetes or Docker host to pull only from the internal registry. This forces you to verify the signatures and surfaces any gaps in your workflow.

Continuous verification in deployment

Verification should not stop at CI. Add admission controls to your cluster or deployment pipeline that reject unsigned or unverified images. Tools like Kyverno or OPA Gatekeeper can enforce signature policies before a workload starts.

In a lab, define a simple policy that only allows images signed by your CI identity. This helps you validate that the policy works and that developers understand how to fix failures when signatures are missing.

Verification step

Add a verification stage to your deployment pipeline. This ensures only signed artifacts are deployed.

cosign verify --key cosign.pub myregistry.local/app:${TAG}

If verification fails, block the deployment and investigate. This simple guard stops a large class of supply chain issues.

Lab checklist

Use this checklist to validate your supply chain controls:

• Generate an SBOM and confirm it matches the built artifact.
• Sign the artifact and verify it in a separate CI stage.
• Store provenance alongside the artifact and verify the commit hash.
• Enforce an admission policy that blocks unsigned images.

Operational tips

• Keep SBOMs versioned with the artifact.
• Rotate signing keys and track their usage.
• Enforce provenance checks at deploy time.
• Automate vulnerability scanning using the SBOM as input.

Takeaways

Supply chain security is achievable in small teams if you focus on the basics. SBOMs give visibility, SLSA provides provenance, and Sigstore adds integrity. Build these into your CI pipeline now, and you will have a defensible foundation against modern supply chain attacks.