SLSA Level 3: Hardening the Software Supply Chain

javi
Cadena digital representando integridad de software

Following major supply-chain attacks in recent years — SolarWinds, Codecov, 3CX — the community has consolidated a standard for evaluating supply-chain robustness: SLSA (Supply-chain Levels for Software Artifacts). SLSA v1.0 was published in April 2023 and defines four maturity levels. This article focuses on Level 3, which is the realistic and valuable goal for most teams.

The Four Levels

SLSA v1.0 structures maturity as follows:

  • L1: basic provenance. The build system generates an attestation indicating what it built and from what.
  • L2: authenticated provenance. The attestation is signed by a trusted build service, not by an individual.
  • L3: isolated and reproducible build. Each build runs in an ephemeral, independent environment, without influence from prior builds or users.
  • L4: two independent reviewers approve every change. Maximum guarantee.

Progression isn’t linear — L3 is a major qualitative leap from L2, and L4 is aspirational for most.

Why L3 Is the Realistic Goal

The L2 → L3 leap eliminates the most common attack vectors in supply chains:

  • Build contamination: builds reusing cache or state from prior builds, letting a compromise persist across builds.
  • Malicious developer machine: a developer’s local environment gets compromised and uploads malicious binaries alongside clean source.
  • Insider threat: an internal engineer with build-system access can modify artefacts without traceability.

With L3, every build runs in a new environment with no prior state, applying an epistemic cut: the only input is source code, and any anomaly is traceable to the commit.

How to Reach L3 with GitHub Actions

GitHub Actions makes L3 feasible with reusable workflows and OIDC for secret-less signing. A typical L3 pipeline looks like:

name: Build and Sign
on:
  push:
    tags: ['v*']

permissions:
  id-token: write   # For OIDC → Sigstore
  contents: read
  packages: write   # For publishing to GHCR

jobs:
  build:
    uses: slsa-framework/slsa-github-generator/.github/workflows/generator_container_slsa3.yml@v1.9.0
    with:
      image: ghcr.io/${{ github.repository }}
      registry-username: ${{ github.actor }}
    secrets:
      registry-password: ${{ secrets.GITHUB_TOKEN }}

This reusable workflow:

  1. Builds the image on an ephemeral GitHub runner.
  2. Generates a provenance attestation per SLSA schema.
  3. Signs the attestation with OIDC via Sigstore.
  4. Pushes image + attestation to the registry.

Consumer-side verification:

cosign verify-attestation \
  --certificate-identity-regexp '^https://github.com/your-org/your-repo/' \
  --certificate-oidc-issuer 'https://token.actions.githubusercontent.com' \
  ghcr.io/your-org/your-image:v1.0.0

If it verifies, you know the image:

  • Was built by your specific repository.
  • On an ephemeral GitHub runner.
  • From the commit indicated in the attestation.
  • Without human intervention between source and binary.

Beyond GitHub Actions

Other CI systems have added similar capabilities:

  • GitLab CI with OIDC and cosign.
  • Buildkite with native attestations since 2023.
  • Tekton + Chains for K8s clusters.
  • Jenkins with cosign plugins, though less integrated.

In all cases, the key is the combo of isolated-build + signature-anchored-in-pipeline-identity, not shared keys.

Operational Challenges

Though L3 is reachable, there are frictions:

  • Verification at deployment point. Signing is useless if nobody verifies. Integrating verification in the Kubernetes admission controller (Kyverno, Gatekeeper, sigstore-policy-controller) is the natural next step.
  • Third-party dependencies. Your own chain may be L3, but if you depend on 50 attestation-less packages, the real chain is as strong as its weakest link. Here broad Sigstore adoption comes in.
  • Reproducibility. SLSA L4 requires byte-for-byte reproducible builds. Hard with most current stacks. L3 requires isolation, not reproducibility — less demanding but enough for most threat models.

What to Do in 2023

For teams starting out:

  1. Audit current state. Are your builds hermetic? Is there interactive human access to the build? Are artefacts signed?
  2. Pick a pilot image. Start with a critical component (main service image). Migrate its pipeline to L3 before replicating.
  3. Adopt reusable workflows. Rather than writing each step, use those from slsa-github-generator — they’re audited.
  4. Add cluster-side verification. Even as warn-only at first, start measuring which images don’t verify to understand real state.

See our previous coverage of 2023 supply-chain attacks for context on why SLSA matters now.

Conclusion

SLSA L3 is achievable with mature tooling and justifies investment for any team producing commercial or critical software. The technical path exists; what’s missing is organisational decision to invest in integrity before the next incident makes it urgent.

Follow us on jacar.es for more on DevSecOps, supply chain, and platform security.

Entradas relacionadas