Supply-Chain Security with SLSA

By Khimananda Oli | Last reviewed: August 2026

Software delivery pipelines are now the primary attack surface for modern applications, making supply-chain security with SLSA essential for any team shipping code in 2026. Without verifiable provenance, you cannot distinguish legitimate builds from compromised artifacts injected by malicious actors or breached CI systems. This guide provides the concrete implementation steps needed to generate, sign, and verify SLSA attestations within your existing infrastructure.

What is supply-chain security with SLSA and why does it matter?

The Supply-chain Levels for Software Artifacts (SLSA) framework defines four progressive levels of integrity assurance. Most teams should target SLSA Level 3 as the baseline for production workloads in 2026, as it guarantees that build artifacts were produced by a trusted builder from verified source code without manual intervention. Achieving this level directly supports SOC 2 Type II and ISO 27001 audit evidence by providing cryptographic proof of build integrity rather than relying on procedural documentation alone.

A common mistake I see when helping Nepali startups and global enterprises alike is treating secrets management as sufficient supply-chain protection. Vault secures credentials, but it does not prove that the binary running in production actually came from your approved source repository. SLSA closes this gap by creating an unbroken chain of custody. For teams already managing complex deployments, integrating SLSA complements strategies like those outlined in my guide on building CI/CD pipelines with GitLab CI, adding a verification layer that detects post-build tampering.

How do you generate SLSA provenance in GitHub Actions?

GitHub Actions remains the most accessible path to SLSA Level 3 because the platform itself acts as the trusted builder. The official slsa-framework/slsa-github-generator workflow isolates the build process from the repository contents, preventing compromised repo scripts from influencing the provenance generation. This isolation is the critical distinction between SLSA Level 2 and Level 3.

Configure the reusable workflow

Create a dedicated workflow file at .github/workflows/release.yml that calls the generator. Never inline build logic in the same job that generates provenance; the separation is what makes the attestation trustworthy.

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

permissions: read-all

jobs:
  build:
    permissions:
      id-token: write   # Required for keyless signing
      contents: write   # Required to attach provenance
      packages: write   # Required if pushing to GHCR
    uses: slsa-framework/slsa-github-generator/.github/workflows/[email protected]
    with:
      image: ghcr.io/${{ github.repository }}
      digest: ${{ needs.build-image.outputs.digest }}
      registry-username: ${{ github.actor }}
    secrets:
      registry-password: ${{ secrets.GITHUB_TOKEN }}

The id-token: write permission enables OIDC-based keyless signing through Sigstore Fulcio. This eliminates long-lived signing keys entirely — a major win for teams managing least-privilege access patterns across environments. The resulting attestation bundle contains the build recipe, environment details, and entry point, all bound to the artifact digest and signed with an ephemeral certificate tied to the GitHub Actions workload identity.

Common pitfalls in provenance generation

• Mutable tags: Never use latest or branch names as the primary artifact reference in provenance. Always pin to immutable digests (sha256:abc123…). Tags can be moved; digests cannot.
• Self-hosted runners: If you use self-hosted runners, you inherit responsibility for runner isolation. SLSA Level 3 assumes ephemeral, isolated build environments. Audit your runner provisioning rigorously or stick to GitHub-hosted runners for high-assurance builds.
• Multi-platform builds: Docker multi-platform manifests require separate provenance per platform digest. The generator handles this automatically in v2.x, but verify each platform's attestation independently during verification.

How do you verify SLSA attestations before deployment?

Generating provenance is only half the equation. Verification must happen at the enforcement point — typically your Kubernetes admission controller or container registry gate. In practice, I deploy Sigstore Policy Controller as a validating webhook that rejects any image lacking a valid SLSA Level 3 attestation matching my expected builder identity.

Install and configure Policy Controller

1. Install via Helm into your cluster: helm install policy-controller sigstore/policy-controller --namespace cosign-system --create-namespace
2. Create a ClusterImagePolicy resource that specifies the accepted builder identity and SLSA level:

   apiVersion: policy.sigstore.dev/v1beta1
   kind: ClusterImagePolicy
   metadata:
     name: slsa-level3-required
   spec:
     images:
       - glob: "ghcr.io/my-org/**"
     authorities:
       - keyless:
           url: https://fulcio.sigstore.dev
           identities:
             - issuer: https://token.actions.githubusercontent.com
               subject: https://github.com/my-org/my-repo/.github/workflows/release.yml@refs/tags/v*
         attestations:
           - name: slsa-provenance
             predicateType: https://slsa.dev/provenance/v1
             policy:
               type: cue
               data: |
                 predicate.buildDefinition.buildType: "https://github.com/slsa-framework/slsa-github-generator/generic@v1"

3. Test with a known-good image and a deliberately unsigned image to confirm enforcement works before applying to production namespaces.

This configuration binds trust to the specific workflow file and tag pattern, not just the repository. A compromised branch or fork cannot produce valid attestations because the subject identity will not match. This precision is what separates real supply-chain security with SLSA from superficial checkbox compliance.

How does SLSA compare to SBOM-only approaches?

Many organizations adopted Software Bill of Materials (SBOM) generation after executive orders mandated transparency, but SBOMs alone do not provide integrity guarantees. Understanding the distinction prevents costly misalignment between your tooling and your actual risk profile.

In my experience supporting SOC 2 audits, SBOMs satisfy the "asset inventory" control, while SLSA attestations satisfy "change management integrity" and "deployment authorization" controls. You need both, but conflating them leaves dangerous gaps. Teams deploying to regulated environments should treat SBOMs as complementary metadata attached alongside SLSA provenance, not as a replacement. For infrastructure provisioning specifically, combining SLSA with Terraform-based IaC practices ensures that both application artifacts and infrastructure state have verifiable lineage.

Securing your pipeline end-to-end

Implementing supply-chain security with SLSA is not a one-time project but an ongoing discipline that compounds with every release cycle. Start with SLSA Level 3 on your most critical services, verify attestations at your cluster boundary, and expand coverage as your tooling matures. The investment pays dividends during incident response, compliance audits, and vendor assessments where provenance evidence replaces hours of manual reconciliation. If your team needs help designing a verification strategy that fits your existing CI/CD topology and compliance requirements, reach out to discuss your specific architecture.