Supply Chain Security Implementation: SLSA, Sigstore, in-toto

Supply Chain Security: SLSA, Sigstore, in-toto

Imagine: your CI built an image, but someone replaced the base image with a malicious one — how would you know? Without supply chain protection, you are blind. Attacks on SolarWinds Orion, XZ Utils, and event-stream in npm showed that compromise happens not through your code but through build tools or dependencies. We have implemented supply chain security systems for 15+ projects, reducing mean time to detect incidents (MTTR) by 40% and saving clients millions in downtime.

One case: a large fintech client discovered their CI agent was compromised through a vulnerable dependency in the build image. In 2 weeks we implemented signing of all images using Cosign + Sigstore keyless, set up SLSA provenance and a Kyverno admission webhook. Now every image is verified at deploy time, and unauthorized changes are blocked.

Why SLSA is the de-facto standard for secure supply chains?

SLSA (Supply-chain Levels for Software Artifacts) defines four maturity levels for the build process. In real projects, the target is SLSA Level 3, where the build environment is isolated and provenance is signed and linked to source code.

Provenance is a JSON document containing the commit SHA, build initiator, build parameters, and artifact digest. Without it, verifying origin is impossible.

How Sigstore eliminates key management?

Sigstore solves the main problem of classic signing — storing and rotating private keys. Instead, it uses keyless signing via OIDC:

1. The CI/CD pipeline requests an OIDC token from the provider (GitHub Actions, GitLab, GCP).
2. Fulcio (CA from Sigstore) verifies the token and issues a short-lived certificate (10 minutes).
3. Cosign signs the image; the certificate is recorded in Rekor — an append-only log.

This approach is 3 times faster to set up than PGP and requires no key rotation.

# GitHub Actions: signing container image via Cosign + Sigstore keyless
- name: Install Cosign
  uses: sigstore/cosign-installer@v3
- name: Sign container image
  run: |
    cosign sign --yes \
      ${{ env.REGISTRY }}/${{ env.IMAGE }}@${{ steps.build.outputs.digest }}
    env:
      COSIGN_EXPERIMENTAL: "true"

Verification at deploy:

cosign verify \
  --certificate-identity-regexp="https://github.com/myorg/myrepo/.github/workflows/.*" \
  --certificate-oidc-issuer="https://token.actions.githubusercontent.com" \
  ghcr.io/myorg/myapp:v1.2.3

If the signature is missing or the certificate does not match, the command returns an error. OPA Gatekeeper or Kyverno can use this check as an admission webhook in Kubernetes.

Generating SLSA Provenance in GitHub Actions

jobs:
  build:
    outputs:
      image: ${{ steps.image.outputs.image }}
      digest: ${{ steps.build.outputs.digest }}
    steps:
      - name: Build and push
        id: build
        uses: docker/build-push-action@v5
        with:
          push: true
          tags: ${{ env.REGISTRY }}/${{ env.IMAGE }}:${{ github.sha }}
          provenance: needs: build
        uses: slsa-framework/slsa-github-generator/.github/workflows/[email protected]
        with:
          image: ${{ needs.build.outputs.image }}
          digest: ${{ needs.build.outputs.digest }}
        secrets:
          registry-username: ${{ secrets.REGISTRY_USER }}
          registry-password: ${{ secrets.REGISTRY_PASSWORD }}

generator_container_slsa3.yml from SLSA GitHub Generator runs in an isolated reusable workflow, ensuring SLSA Build Level 3 — the pipeline runner cannot modify provenance.

How in-toto complements SLSA?

In-toto allows you to define a supply chain layout: specific steps (clone, build, test, package, sign) and who is authorized to perform them. Each step creates link metadata — a signed file with the step's inputs/outputs.

# Build step with link recording
in-toto-run \
  --step-name build \
  --key developer.pem \
  --products dist/ \
  -- make build

# Final verification of the entire chain
in-toto-verify \
  --layout root.layout \
  --layout-keys root.pub \
  --link-dir ./links/

In-toto is actively used in TUF for securing package repositories — this is how PyPI and Debian packages are protected.

Implementation process for supply chain security

Phase 1 — Image signing and verification (1 week)

• Set up Cosign in CI/CD pipelines
• Configure Kyverno/OPA policies to check signatures at deploy
• Registry of signed images, reject unsigned images in production namespace

Phase 2 — SLSA Provenance (1 week)

• Integrate slsa-github-generator into build pipelines
• Store provenance alongside the image in the registry (as OCI attestation)
• Set up automatic provenance verification at deploy

Phase 3 — Dependency and artifact verification (1-2 weeks)

• Verify third-party dependencies via Dependency Review Action
• Configure npm audit signatures to check npm package signatures
• Integrate with Sigstore Policy Controller

Phase 4 — in-toto layout (optional, 1-2 weeks)

• Only if full chain verification is required: needed for compliance frameworks like DISA STIG or when artifacts are distributed through third parties

What is included in the work

• Audit of current CI/CD stack and determination of target SLSA level
• Configuration of Cosign and keyless signing for all images
• Integration of SLSA Provenance generation into pipelines
• Implementation of signature verification policies via Kyverno/OPA
• Documentation of runbook and team training
• Support during pilot production operation (2 weeks)