Software Supply Chain Security: SLSA and Sigstore on Kubernetes

Key takeaway: SLSA provides a framework for measuring build integrity. Sigstore provides free tooling (Cosign, Fulcio, Rekor) to sign and verify artifacts without managing long-lived private keys. Together they let you enforce "only signed, verified images run in this cluster" at the Kubernetes admission layer.

Why Supply Chain Security Matters

The software supply chain — the pipeline from source code to running artifact — has become a primary attack vector. The SolarWinds compromise (2020) injected malware into signed builds. The XZ Utils backdoor (2024) was inserted by a long-term social engineering campaign into a widely used open-source library. Log4Shell (2021) affected hundreds of thousands of applications through a single transitive dependency.

Traditional perimeter security does not protect against supply chain attacks. An attacker who compromises your build pipeline or a dependency you use bypasses all your runtime controls — the malicious code arrives already signed and passes all your tests. Supply chain security addresses the gap: verifying the integrity of the path from source code to deployment.

SLSA: Build Integrity Levels

SLSA (pronounced "salsa" — Supply-chain Levels for Software Artifacts) is a security framework from Google, now under the OpenSSF, that defines levels of build integrity through provenance attestations.

SLSA Level 1: Provenance exists. The build process generates a signed document stating who built this artifact, from what source, and on what date. Minimal integrity — the signer could be the developer's laptop.

SLSA Level 2: Hosted build service. Build runs on a managed CI/CD service (GitHub Actions, GitLab CI, Google Cloud Build) that generates signed provenance. The build environment is not controlled by the developer.

SLSA Level 3: Hardened build. The build service provides isolation guarantees — each build runs in an ephemeral environment with no persistent state and cannot access secrets from other builds. Provenance is non-falsifiable by the build service operator.

SLSA Level 4: Hermetic, reproducible builds. All inputs are pinned and declared. Given the same inputs, the build produces bit-for-bit identical output. Two-party review required for all changes.

Most organizations target SLSA Level 2 as their near-term goal — it catches the majority of supply chain attack vectors while being achievable with existing CI/CD infrastructure.

Sigstore: The Signing Infrastructure

Sigstore is a Linux Foundation project providing free, open-source infrastructure for signing software artifacts. It solves the hardest problem in signing: key management. With traditional signing, you generate a key pair, guard the private key forever, distribute the public key, and handle rotation when the private key is compromised. This is operationally expensive and frequently done badly.

Sigstore's keyless signing works differently: instead of a long-lived private key, you use your CI/CD system's OIDC identity (a GitHub Actions workflow, a Google Cloud Build job, an AWS CodeBuild project) to obtain a short-lived certificate (valid for 10 minutes) from Fulcio, the Sigstore certificate authority. The signature and certificate are recorded in Rekor, an append-only transparency log. The private key is ephemeral — it is generated for this signing operation and immediately discarded.

The result: anyone can verify the signature without receiving a public key distribution problem, because verification goes through Rekor's transparency log. You sign with your GitHub Actions identity, and the verifier can confirm "this image was signed by a workflow in the repository github.com/myorg/myrepo during a push to main."

Cosign: Sign and Verify Images

# Install Cosign
curl -O -L "https://github.com/sigstore/cosign/releases/latest/download/cosign-linux-amd64"
chmod +x cosign-linux-amd64
sudo mv cosign-linux-amd64 /usr/local/bin/cosign

# Sign an image (keyless — uses ambient OIDC credentials)
# Run this in a GitHub Actions workflow where OIDC is enabled
cosign sign --yes ghcr.io/myorg/myapp@sha256:abc123...

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

# Verify and get the full cert chain
cosign verify --output json \
  --certificate-identity-regexp=".*" \
  --certificate-oidc-issuer="https://token.actions.githubusercontent.com" \
  ghcr.io/myorg/myapp:latest | jq .

Cosign attaches signatures to images as OCI artifacts stored alongside the image in the same registry. No separate signature store is needed — the registry holds both the image and its signatures.

CI/CD Integration

# .github/workflows/build-sign.yml
name: Build and Sign

on:
  push:
    branches: [main]

permissions:
  contents: read
  packages: write
  id-token: write  # Required for keyless signing

jobs:
  build-sign:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Log in to GitHub Container Registry
        uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}

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

      - name: Install Cosign
        uses: sigstore/cosign-installer@v3

      - name: Sign the image (keyless)
        run: |
          cosign sign --yes \
            ghcr.io/${{ github.repository }}@${{ steps.build.outputs.digest }}

      - name: Generate SBOM
        uses: anchore/sbom-action@v0
        with:
          image: ghcr.io/${{ github.repository }}@${{ steps.build.outputs.digest }}
          artifact-name: sbom.spdx.json

      - name: Attest SBOM
        run: |
          cosign attest --yes \
            --predicate sbom.spdx.json \
            --type spdxjson \
            ghcr.io/${{ github.repository }}@${{ steps.build.outputs.digest }}

Kubernetes Enforcement with Kyverno

Signing images is only half the solution. The other half is refusing to run unsigned images in production. Kyverno provides a ClusterPolicy resource that verifies Sigstore signatures at admission time:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: verify-image-signatures
spec:
  validationFailureAction: Enforce  # Deny admission if verification fails
  background: false
  rules:
    - name: verify-ghcr-images
      match:
        any:
          - resources:
              kinds: [Pod]
      verifyImages:
        - imageReferences:
            - "ghcr.io/myorg/*"
          attestors:
            - entries:
                - keyless:
                    subject: "https://github.com/myorg/*/.github/workflows/*.yml@refs/heads/main"
                    issuer: "https://token.actions.githubusercontent.com"
                    rekor:
                      url: https://rekor.sigstore.dev

With this policy active, any pod that tries to use an image from ghcr.io/myorg/* that was not signed by a GitHub Actions workflow in the myorg organization from the main branch will be rejected before it starts.

SBOM Generation

An SBOM (Software Bill of Materials) is a machine-readable inventory of every software component in an artifact — OS packages, language dependencies, and their transitive dependencies.

# Generate SBOM for a container image using Syft
curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh

# Scan an image and generate SPDX SBOM
syft ghcr.io/myorg/myapp:latest -o spdx-json > sbom.spdx.json

# Scan for vulnerabilities in the SBOM using Grype
grype sbom:sbom.spdx.json

# Attach SBOM to image with Cosign
cosign attest --predicate sbom.spdx.json --type spdxjson \
  ghcr.io/myorg/myapp@sha256:abc123...

When a new CVE is announced (another Log4Shell), you can immediately query your SBOM inventory to find which services are affected — instead of spending days manually checking dependencies.

Rekor: Transparency Log

Rekor is Sigstore's immutable, append-only transparency log — similar to Certificate Transparency for TLS certificates. Every signing operation is recorded in Rekor with the artifact hash, certificate, and timestamp. Anyone can query Rekor to verify a signature or audit what was signed when.

# Install Rekor CLI
go install github.com/sigstore/rekor/cmd/rekor-cli@latest

# Search Rekor for all entries for a specific image hash
rekor-cli search --sha sha256:abc123...

# Get a specific Rekor entry
rekor-cli get --uuid UUID_FROM_SEARCH

# Verify an artifact is in the log
rekor-cli verify --artifact image.tar --signature image.sig --public-key pub.pem

Getting Started Checklist

A practical implementation order for most teams:

1. Add Cosign keyless signing to your main branch CI/CD pipeline for all production image builds.
2. Store SLSA provenance attestations alongside each image in your registry.
3. Generate SBOMs with Syft and attach them to images with Cosign attest.
4. Deploy Kyverno with a policy enforcing signature verification in your staging cluster.
5. After 2-4 weeks of stable staging operation, enable enforcement in production.
6. Set up Grype scanning against your SBOM inventory as part of vulnerability management.

Final Thoughts

Software supply chain security is no longer optional — it is increasingly a contractual and regulatory requirement for enterprise customers and government contracts. The good news is that the tooling (Sigstore, Cosign, Kyverno, Syft) is now mature, free, and integrates cleanly with modern CI/CD workflows. The investment is days of engineering work for a significant reduction in supply chain attack surface.