SLSA Levels in Practice: What Most Organisations Claim vs What Their Pipeline Actually Enforces

A CISO at a UK fintech slides a vendor questionnaire across the procurement table. The answer in the SLSA column is Level 3, attested. Two seats down, the vendor's platform-engineering lead has her phone tilted on her lap, scrolling the CI logs in another tab. Builds run on shared GitHub-hosted runners. Provenance comes from a marketplace action nobody on the team has audited. Two-party review is configured on the release branch, but the admin-override path has been used three times this quarter. Nothing — nothing at all — verifies the provenance at deploy. The questionnaire answer, read honestly by the engineer who has to live with it, is Level 1 with a sign-off form on top.

This is the median. The Supply-chain Levels for Software Artifacts framework — SLSA, pronounced salsa — is the vocabulary the OpenSSF gave the industry for talking about how mature a build pipeline really is. The framework is sound. The audit reality is that most questionnaires claim Level 2 or 3 and most pipelines do not enforce the controls those levels require. This piece is the engineering-audit read.

The Receipts the Regulator Will Ask For

SLSA v1.0 went out the door in April 2023. The market spent the next eighteen months treating it as something for next year. Next year is here.

The EU Cyber Resilience Act passed in 2024. Its supply-chain teeth start biting from late 2027, and on the Commission's reading the scope swallows most enterprise SaaS. Manufacturers of products with digital elements will need to ship an SBOM, demonstrate secure development practices, and prove they can respond to vulnerabilities under a clock. The text never names SLSA. The conformity assessment bodies are reading SLSA as the most mature available framework for the build-track controls anyway, because there is nothing else with the same depth.

FedRAMP Rev 5 cites SLSA explicitly in its supply-chain risk management controls, with the High baseline moving toward binding requirements. The SOC 2 auditors have started asking too — CC8 and CC9 increasingly map to SLSA-shaped practices, and the larger firms now expect a provenance sample in the evidence packet rather than a paragraph of policy language.

The floor is rising. Teams claiming maturity they have not built will spend the next two years explaining gaps to assessors who already know what the right answer looks like.

What Each Level Actually Costs You

Think of SLSA as four rungs on a ladder where each rung removes a specific way an attacker can lie to you about how the build happened.

Level 1 is the rung where you just have a build record. The platform produces a provenance document showing how the artifact was built. The document does not have to be signed. Nobody has to check it. The standard CI workflow running docker build with the SLSA generator action bolted on meets Level 1. This is documentation pretending to be a control.

Level 2 is the rung where the platform vouches for itself. Builds run on a hosted platform — GitHub Actions, GitLab CI, AWS CodeBuild, Google Cloud Build — not on a laptop. Source lives in version control. The provenance is signed by the platform using a credential the workload owner cannot touch, and the signature is verifiable end-to-end. Level 2 is the realistic ceiling for most non-platform-engineering organisations in 2026 and is the level a credible enterprise pipeline should be enforcing today.

Level 3 is the rung where the build environment becomes a hardened system in its own right. Builds are isolated from each other. The steps that produce and sign provenance run in a context the build script cannot modify. Provenance is non-falsifiable — an attacker compromising the build script cannot manufacture a valid provenance file. Two-party review is enforced on release-producing branches. This is the level vendors most frequently claim and most frequently fail to enforce. GitHub-hosted runners are not isolated in the SLSA sense. Two-party review is one branch-protection misconfiguration away from advisory. The signing identity has to be held by the platform, not the workflow, which most marketplace generator actions get subtly wrong in ways that take a careful read of the action's permissions block to catch.

Level 4 used to exist. Pre-1.0 drafts described it: hermetic builds, reproducible builds, two-party review of every dependency. The OpenSSF removed it because the spec was being over-engineered for a market that had not reached Level 2 in volume. Vendor claims of Level 4 readiness have no current normative meaning, and the security questionnaire that asks for it is asking for a thing the spec no longer defines.

The Gap Between the Cheque and the Bank Balance

Three patterns recur across the security questionnaires we read on procurement reviews. Each one is a specific shape of overstatement.

The first is we're SLSA Level 3. On inspection, the builds run on shared GitHub-hosted runners. The provenance is signed by an unaudited marketplace action. Two-party review is configured on main but the release branch has an admin override path that has been used. The build script can write to the same workspace the provenance step reads from. The honest read is Level 2 with a Level 3 aspiration, and that is the generous version.

The second is we use Sigstore and cosign. Real. The build genuinely signs the image on push. The signature is real, the certificate is real, the Rekor entry is real. The verification step is missing. The Kubernetes admission controller never calls cosign. The signing happens; the checking does not.

The third is we enforce in CI. On inspection, a CI check warns on policy violations but is configured as advisory. Admin override is permitted and has been used. Enforcement that can be bypassed without an audit trail is not enforcement; it is suggestion with strong feelings.

The auditor question that catches all three is the same. Show me one build's provenance, end-to-end. Show me the policy that verifies it at deploy. Show me the last time the policy blocked a deploy. A team at the level it claims answers all three within an hour. A team that has to schedule a meeting to find out tells the auditor everything she needs to know.

The Six-Piece Kit That Costs Nothing and Takes a Quarter

A Level 2 pipeline that survives audit has six components. None cost money. The work is entirely in wiring them.

The first is the build platform. GitHub Actions, GitLab CI, or Tekton. The hosted runners are owned by the platform, and the runner identity becomes the signing identity. Workflow permissions are scoped tightly — the workflow that builds production images does not need write access to source, and giving it write access is one of the more common own-goals.

The second is the provenance generator. The SLSA GitHub Generator (slsa-framework/slsa-github-generator), the GitLab SLSA provenance integration, or Tekton Chains. Each emits an in-toto attestation conforming to SLSA Provenance v1.0, recording the source repository, the build invocation, the materials, and the artifacts.

The third is the signing layer. Sigstore cosign signs the provenance and the artifact using an OIDC identity issued by the build platform — for GitHub Actions, the workflow's id-token — not a long-lived key. Fulcio issues a short-lived certificate. Rekor logs the signature in a tamper-evident transparency log. The short-lived credential and the public log are what take this from a signature you have to trust to a signature an outside party can verify.

The fourth is the SBOM. Syft or Trivy in SBOM mode generates a CycloneDX or SPDX document at build, attached as an in-toto attestation and stored as an OCI referrer alongside the image.

The fifth is the artifact registry. Any registry supporting OCI 1.1 referrers — GHCR, GitLab Container Registry, Harbor, ECR, GAR. The artifact, the provenance, and the SBOM all resolvable from the image digest.

The sixth is the component most teams skip. Deploy-time verification. Sigstore policy-controller, Kyverno with Sigstore verifier policies, or OPA Gatekeeper sitting in the Kubernetes admission controller. It verifies the signature against the expected identity, verifies the provenance matches the expected build platform, and blocks deployment if either check fails. This is the difference between a pipeline that produces evidence and a pipeline that enforces controls.

Most production pipelines we review have the first five. They almost never have the sixth.

The Receipt Nobody Cashes

The single most common gap in claimed SLSA maturity is the verification step. Provenance is generated, signed, stored in a registry, never verified at deploy.

The whole point of SLSA is that provenance enables an out-of-band party — the deploying system, the auditor, a downstream consumer — to verify properties of the build they could not otherwise verify. Without verification, provenance is documentation. A signed provenance file nobody checks is the supply-chain equivalent of a vulnerability scan report nobody reads. Worse, it lets the team claim a control they do not have, because the artefact exists and the artefact looks impressive.

The fix is a policy controller in the deploy path. It pulls the signed provenance alongside the image, verifies the signature against the expected signing identity, verifies the provenance conforms to policy, and blocks admission if any check fails. Sigstore policy-controller is the most direct option for Kubernetes. Kyverno with cosign verify policies is the more widely deployed.

The operational discipline is harder than the installation. The verification step has to actually fail deploys when verification fails. Teams that turn the controller on in advisory mode and never move it to enforcing are in the same posture as before — the control is theatre. The cultural work of accepting that a misconfigured pipeline will block production deploys is the work. The technical work is a Helm chart.

Why the Level 3 Claim Almost Never Survives a Read

Level 3 requires hardening that GitHub-hosted runners do not provide out of the box. Three specific properties.

Isolation. Two builds in the same environment must not influence each other. On GitHub-hosted runners, one workflow can in principle write to a cache another reads from. Genuine isolation requires ephemeral runners, isolated infrastructure (Firecracker or Kata microVMs, single-tenant per build), or a build platform with stronger isolation guarantees. The Level 3 claim on shared hosted runners is, in the spec's own definitions, an overstatement.

Non-falsifiable provenance. If the build script can write to the workspace the provenance step reads from, the provenance is forgeable by a compromised build. The SLSA generator action runs the provenance step in a separate reusable workflow with restricted permissions. Teams wiring their own provenance generation into the same workflow as the build step typically do not get this right. The reusable-workflow pattern is non-negotiable for Level 3 and is the single most common subtle misconfiguration.

Two-party review enforced. Branch protection must require review from someone other than the committer, not overridable by repository administrators without an audited break-glass procedure. Most repositories permit admin override. Most teams have used it. Both demote enforcement from binding to advisory.

Level 3 is achievable. Teams achieving it treat the build platform as production infrastructure — versioned, monitored, governed, with break-glass paths that produce audit trails. Most teams do not.

The Twenty-Four-Hour Test

If a vendor's questionnaire claims SLSA Level 3, the buyer's test is concrete. Ask for one provenance JSON for one build that shipped in the last week. Ask for the verification policy that gates deploy on that provenance. Give the vendor twenty-four hours.

A vendor genuinely at Level 3 can produce both within a working day. The provenance is a JSON file. The policy is a Kubernetes manifest or equivalent. A vendor that needs a week, produces a partial answer, or returns marketing material is a vendor whose claim should be downgraded in the buyer's risk model. The same test applies internally — pick one production artifact, resolve its provenance, verify the signature, confirm source and build invocation match what was approved, and show the admission policy that blocks a deploy missing valid provenance. A team at credible Level 2 produces these within an hour.

SLSA-for-ML is emerging as a parallel track. The OpenSSF AI/ML Working Group has draft guidance; the spec is not yet at v1.0. Model weights stored in an OCI registry can already carry provenance and SBOM attestations as referrers, signed with cosign, verified at deploy. The companion piece on AI Workload Posture Management treats model-version pinning and training-data lineage as posture controls; the SLSA reading is that they should also be supply-chain controls.

What We Would Build on Monday

For a regulated client building greenfield in 2026, the reference Level 2 pipeline is unglamorous and well-understood. GitHub Actions for the build platform. The SLSA GitHub Generator as a reusable workflow producing provenance for every artifact. Cosign signing artifact and provenance using the workflow's OIDC identity, with certificates from public Fulcio and signatures logged in public Rekor — private where required. Syft generating a CycloneDX SBOM at build, stored as an OCI 1.1 referrer. Sigstore policy-controller in production Kubernetes, gating admission in enforcing mode from day one. Branch protection requiring two-party review, admin override disabled, with a documented break-glass procedure that produces a signed audit-log entry every time it fires.

The pipeline is not exotic. The components are widely deployed with mature documentation. The work is in the wiring, and in the discipline of moving the policy controller from advisory to enforcing — accepting that this will, in the first month, block deploys until the configuration is correct. Teams that accept the first-month pain ship a control. Teams that flinch ship documentation.

When the CRA conformity body asks for an attested build for your highest-risk product line in 2027, the answer is either a file you can produce in five minutes or a project plan for the next two quarters. Which one are you going to be holding?

Companion content

• AI Workload Posture Management: The CSPM Gap
• Hardened Containers for AI Workloads: The Tier Decision
• SOC 2 for AI Deployments: Trust Service Criteria
• The AI Act Enforcement Deadline

How to engage

If your team is preparing for a CRA conformity assessment, a FedRAMP Rev 5 audit, or a SOC 2 examination and the questionnaire is starting to ask about supply-chain attestations, we can audit your pipeline against the SLSA spec, identify the gap between claim and enforcement, and ship the reference Level 2 toolchain with the verification step wired in. Talk to us at creativeminds.dev/contact.