Software Supply Chain Security with Sigstore and SLSA Framework

Software Supply Chain Security: Sigstore and SLSA

Supply chain security Sigstore addresses one of the most critical challenges in modern software development — ensuring that the code you deploy is exactly what was built from your source code, untampered and from a trusted source. After high-profile attacks like SolarWinds and Log4Shell, supply chain security has moved from a nice-to-have to a regulatory requirement. Therefore, every engineering team needs to implement artifact signing, provenance verification, and dependency auditing. The threat is no longer hypothetical: attackers increasingly target the build pipeline itself, because compromising one widely used package or base image can fan out to thousands of downstream consumers.

Sigstore provides keyless signing and verification for software artifacts, eliminating the complexity of managing signing keys. Moreover, the SLSA (Supply-chain Levels for Software Artifacts) framework defines progressive maturity levels for supply chain security. Consequently, organizations can start with basic signing and work toward comprehensive provenance that proves exactly how each artifact was built. The sections below explain how the keyless flow actually works under the hood, how to wire verification into a real deployment, and where these tools introduce friction you should plan for.

Supply Chain Security Sigstore: Artifact Signing

Sigstore uses ephemeral certificates tied to developer identities (via OIDC) instead of long-lived signing keys. This means there are no keys to manage, rotate, or protect. Furthermore, every signature is recorded in a tamper-proof transparency log, providing a public audit trail of all signed artifacts.

# Sign a container image with cosign (Sigstore)
cosign sign --yes ghcr.io/myorg/myapp:v1.2.3

# Sign with GitHub Actions OIDC identity (keyless)
# The signature includes the workflow, commit SHA, and trigger
cosign sign --yes \
  --certificate-identity-regexp="https://github.com/myorg/.*" \
  --certificate-oidc-issuer="https://token.actions.githubusercontent.com" \
  ghcr.io/myorg/myapp@sha256:abc123

# Verify a signed image
cosign verify \
  --certificate-identity-regexp="https://github.com/myorg/.*" \
  --certificate-oidc-issuer="https://token.actions.githubusercontent.com" \
  ghcr.io/myorg/myapp:v1.2.3

# Attach SBOM to container image
cosign attach sbom --sbom sbom.spdx.json ghcr.io/myorg/myapp:v1.2.3

How Keyless Signing Actually Works

The phrase “keyless” is slightly misleading, and understanding the real mechanism builds the trust you need to rely on it. Behind the scenes, cosign does generate a short-lived key pair in memory. It then obtains an OIDC identity token — from GitHub Actions, Google, or another configured issuer — and presents that token to Fulcio, Sigstore’s certificate authority. Fulcio verifies the token and issues an X.509 certificate that binds the ephemeral public key to the verified identity, valid for only about ten minutes. The signing happens, the certificate and signature are published to the Rekor transparency log, and then the private key is discarded.

This design is clever because the security no longer depends on protecting a secret indefinitely. Instead, it depends on the integrity of the OIDC issuer and the append-only Rekor log. Because Rekor entries are timestamped and tamper-evident, a verifier can confirm that the signature was created during the certificate’s brief validity window, even though that certificate has long since expired. As a result, there is genuinely no key sitting in a vault waiting to be stolen — the attack surface shifts from key custody to identity provider trust, which most organizations already manage carefully.

SLSA Framework: Provenance Levels

SLSA defines progressive levels of supply chain security maturity. Build Level 1 requires that provenance exists and is distributed. Build Level 2 requires a hosted build platform that signs the provenance. Build Level 3 requires a hardened build platform with strong isolation, so the provenance is non-falsifiable even by the project’s own maintainers. Furthermore, each level builds on the previous one, providing a clear improvement roadmap for organizations.

# GitHub Actions workflow with SLSA Level 3 provenance
name: Build and Sign
on:
  push:
    tags: ['v*']

permissions:
  contents: read
  packages: write
  id-token: write  # Required for Sigstore OIDC

jobs:
  build:
    runs-on: ubuntu-latest
    outputs:
      digest: ${{ steps.build.outputs.digest }}
    steps:
      - uses: actions/checkout@v4

      - name: Build and push image
        id: build
        uses: docker/build-push-action@v5
        with:
          push: true
          tags: ghcr.io/myorg/myapp:${{ github.ref_name }}

      - name: Generate SBOM
        uses: anchore/sbom-action@v0
        with:
          image: ghcr.io/myorg/myapp@${{ steps.build.outputs.digest }}
          format: spdx-json
          output-file: sbom.spdx.json

      - name: Sign image with Sigstore
        uses: sigstore/cosign-installer@v3
      - run: cosign sign --yes ghcr.io/myorg/myapp@${{ steps.build.outputs.digest }}

      - name: Attach SBOM
        run: cosign attach sbom --sbom sbom.spdx.json ghcr.io/myorg/myapp@${{ steps.build.outputs.digest }}

  # SLSA provenance generator
  provenance:
    needs: build
    uses: slsa-framework/slsa-github-generator/.github/workflows/generator_container_slsa3.yml@v2.0.0
    with:
      image: ghcr.io/myorg/myapp
      digest: ${{ needs.build.outputs.digest }}

Notice that the build job pins the image by digest, not by mutable tag, before generating the SBOM and provenance. This detail is essential — a tag like v1.2.3 can be overwritten to point at a different image, whereas a sha256 digest is content-addressed and immutable. The SLSA provenance attests to that specific digest, the build entry point, the source repository, and the trigger, so a verifier can later prove the artifact came from this exact workflow run and nothing else.

Verification in Kubernetes

Use admission controllers to enforce signature verification before deploying containers. Sigstore’s policy-controller rejects any unsigned or improperly signed images. Additionally, you can require SLSA provenance at a specific level, ensuring only properly built artifacts enter your cluster. The key principle is enforcement at the boundary — signing artifacts is pointless if nothing checks the signatures, so the verification gate is where supply chain security actually pays off.

# sigstore policy-controller ClusterImagePolicy
apiVersion: policy.sigstore.dev/v1beta1
kind: ClusterImagePolicy
metadata:
  name: require-signed-myorg-images
spec:
  images:
    - glob: "ghcr.io/myorg/**"
  authorities:
    - keyless:
        url: https://fulcio.sigstore.dev
        identities:
          - issuer: https://token.actions.githubusercontent.com
            subjectRegExp: "https://github.com/myorg/.*"
      ctlog:
        url: https://rekor.sigstore.dev

SBOMs, Dependency Auditing, and the Last Mile

Signing proves who built an artifact, but it says nothing about what is inside it. That gap is why a Software Bill of Materials matters. An SBOM, generated in SPDX or CycloneDX format, enumerates every dependency and version baked into the image. When the next Log4Shell-class vulnerability lands, teams with stored SBOMs can query their inventory in minutes to find every affected artifact, rather than rebuilding and rescanning everything under time pressure. Pairing the SBOM with a vulnerability scanner closes the loop between provenance and patch management.

# Scan the SBOM against known CVEs before promotion
grype sbom:sbom.spdx.json --fail-on high

# Continuously check a deployed image as new CVEs are published
grype ghcr.io/myorg/myapp@sha256:abc123 -o json

A common pattern is to fail the pipeline on high-severity findings before promotion, while still recording the SBOM so it can be re-scanned later when new CVEs are disclosed against dependencies that were clean at build time. This matters because a clean scan today is not a clean scan forever — vulnerabilities are discovered in already-shipped code constantly.

When NOT to Use It, and the Trade-offs

These tools are genuinely valuable, but they are not free of friction, and pretending otherwise sets teams up to abandon them. The most significant honest caveat is operational dependency: keyless verification at deploy time reaches out to Fulcio and Rekor, so a public outage of those services, or a network partition, can block your deployments unless you cache trust material or run private infrastructure. For organizations with strict availability requirements, the docs recommend mirroring the trust root and considering a self-hosted Sigstore stack, which reintroduces some operational burden.

There is also a maturity-versus-cost calculation. Achieving SLSA Build Level 3 requires an isolated, hardened build platform, and for a small internal tool that never leaves your own cluster, that effort rarely pays off — Level 1 provenance plus basic signing may be entirely sufficient. Similarly, enforcing strict admission policies can break legitimate workflows in unexpected ways, such as third-party base images or vendor sidecars that are not signed by your identity. The pragmatic path is to start in warn-only mode, watch what the policy would have blocked, and only switch to hard enforcement once your own pipeline reliably produces signed, provenanced artifacts.

Getting Started

Start with SLSA Build Level 1 — add provenance metadata to your CI/CD pipeline. Then implement Sigstore signing for container images and binaries. Finally, enforce verification in your deployment pipeline, beginning in warn mode and graduating to enforcement. See the Sigstore documentation and SLSA framework for detailed implementation guides.

Key Takeaways

• Keyless signing replaces long-lived keys with short-lived OIDC-bound certificates and a tamper-evident Rekor log
• Always pin and sign by image digest, never by mutable tag, so provenance attests to immutable content
• Verification at an admission controller is where signing actually delivers value — enforce at the boundary
• Store SBOMs so you can re-scan shipped artifacts when new CVEs land, not just at build time
• Plan for the operational dependency on Sigstore services and adopt enforcement progressively

In conclusion, supply chain security Sigstore and the SLSA framework provide practical, implementable solutions for protecting your software delivery pipeline. Keyless signing eliminates key management headaches, transparency logs provide auditing, and progressive SLSA levels give you a clear maturity roadmap. Start signing your artifacts today, enforce verification at the deployment boundary, and keep your SBOMs — the tooling has never been more accessible.