A CISO at a UK fintech sends a vendor questionnaire response across the procurement table. SLSA Level 3, attested. The vendor's platform-engineering lead, sitting in the same meeting, quietly checks the CI logs on their phone. Builds run on shared GitHub-hosted runners. Provenance is generated by an unaudited marketplace action. Two-party review on the release branch is configured but admin override has been used. Nothing verifies the provenance at deploy. The questionnaire answer is, in the engineering-honest reading, Level 1 with a manual approval gate.
This is the median. The Supply-chain Levels for Software Artifacts framework — SLSA, pronounced "salsa" — was published by the OpenSSF to give organisations a shared vocabulary for build-pipeline maturity. 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. The piece below is the engineering-audit read.
Key takeaways
- SLSA v1.0 defines three Build track levels — Level 1 (provenance generated), Level 2 (hosted build, signed provenance, version-controlled source), Level 3 (hardened, isolated, non-falsifiable provenance, two-party review). Level 4 was deprecated in v1.0.
- Level 2 is the realistic ceiling for most non-platform-engineering organisations in 2026. Claims of Level 3 should be treated as marketing until the vendor produces one provenance JSON, one verification policy, and a build-platform attestation demonstrating isolation.
- The verification gap is where most SLSA claims fall apart. Provenance is generated and never checked at deploy. The fix is a policy controller — Sigstore policy-controller, Kyverno, or OPA Gatekeeper — gating admission on signature verification.
- The reference Level 2 toolchain is GitHub Actions (or GitLab CI / Tekton) plus the SLSA GitHub generator, cosign for signing, Syft for SBOM, in-toto attestations stored as OCI referrers, and a policy controller gating Kubernetes admission. None of these tools cost money. The work is in wiring them and proving the wiring holds.
- The EU Cyber Resilience Act starts requiring supply-chain attestations from late 2027; FedRAMP Rev 5 references SLSA; SOC 2 auditors increasingly ask. Teams without a credible Level 2 pipeline today will be under remediation pressure in eighteen months.
Why SLSA matters in 2026
SLSA v1.0 was published in April 2023 and the market spent eighteen months treating it as aspirational. The regulatory environment has caught up.
The EU Cyber Resilience Act passed in 2024 and starts applying its main supply-chain obligations from late 2027. Manufacturers of products with digital elements — which on the Commission's reading includes most enterprise SaaS — will need to provide an SBOM, demonstrate secure development practices, and respond to vulnerabilities. The text does not name SLSA, but the conformity assessment bodies are reading SLSA as the most mature available framework for the build-track controls.
FedRAMP Rev 5 references SLSA in the supply-chain risk management controls; the High baseline is moving toward binding requirements. SOC 2 auditors have started asking — CC8 and CC9 increasingly map to SLSA-shaped practices, and the bigger audit firms now ask for provenance samples in evidence packets.
The regulatory floor is rising. Teams claiming maturity they have not built will be explaining gaps to assessors.
The four levels, honestly
Level 1 — provenance exists. The build platform produces a provenance document recording how the artifact was built. It does not have to be signed or verified. The standard CI workflow that runs docker build with the SLSA generator action bolted on meets Level 1.
Level 2 — signed provenance from a hosted build platform. The build runs on a hosted build platform — GitHub Actions, GitLab CI, AWS CodeBuild, Google Cloud Build — not a developer laptop. Source is version-controlled. Provenance is signed by the platform using a credential the workload owner does not have direct access to, and the signature is verifiable end-to-end. This is the realistic ceiling for most non-platform-engineering organisations and the level a credible enterprise pipeline should be enforcing.
Level 3 — hardened build, isolated environment, non-falsifiable provenance. Builds are isolated such that one cannot influence another. The build platform is hardened — 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 produce 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 must be held by the platform, not the workflow, which most marketplace generator actions get subtly wrong.
Level 4 (deprecated in v1.0). Pre-1.0 drafts described a Level 4 requiring hermetic, reproducible builds and two-party review of all dependencies. The OpenSSF removed it: 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.
What organisations claim vs what they enforce
Three patterns recur across the security questionnaires we read on procurement reviews.
"We're SLSA Level 3." On inspection: builds run on shared GitHub-hosted runners, 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, and the build script can write to the same workspace the provenance step reads from. At best, Level 2 with a Level 3 aspiration.
"We use Sigstore and cosign." On inspection: the build signs the image on push; nothing verifies the signature at deploy. The Kubernetes admission controller does not call cosign. The signing step is real; the verification step is missing.
"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.
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 claimed answers all three within an hour. The shape of the answer tells the auditor more than the questionnaire response.
The reference toolchain for a real Level 2
A Level 2 pipeline that survives audit has six components. None cost money. The work is in wiring them.
Build platform. GitHub Actions, GitLab CI, or Tekton. Hosted runners owned by the platform; the runner identity is the signing identity. Workflow permissions scoped — the workflow that builds production images does not need write access to source.
Provenance generator. The SLSA GitHub Generator (slsa-framework/slsa-github-generator), the GitLab SLSA provenance integration, or Tekton Chains. Emits an in-toto attestation conforming to SLSA Provenance v1.0, recording source repository, build invocation, materials, and artifacts.
Signing layer. Sigstore cosign signs provenance and 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.
SBOM. Syft (or Trivy in SBOM mode) generates a CycloneDX or SPDX SBOM at build, attached as an in-toto attestation and stored as an OCI referrer alongside the image.
Artifact registry. Any registry supporting OCI 1.1 referrers — GHCR, GitLab Container Registry, Harbor, ECR, GAR. Artifact, provenance, and SBOM all resolvable from the image digest.
Deploy-time verification. The component most teams skip. Sigstore policy-controller, Kyverno (with Sigstore verifier policies), or OPA Gatekeeper in the Kubernetes admission controller. Verifies the signature against the expected identity, verifies the provenance matches the expected build platform, and blocks deployment if either fails. The difference between a pipeline that produces evidence and a pipeline that enforces controls.
Most production pipelines we review have the first five and not the sixth.
The verification gap
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 nobody checks is the supply-chain equivalent of a vulnerability scan report nobody reads.
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 that 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 harder than installing the controller.
Why Level 3 is harder than the claim
Level 3 requires hardening GitHub-hosted runners do not provide out of the box.
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.
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.
The procurement implication
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 the provenance. Give the vendor 24 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 cmdev would build today
For a regulated client building greenfield in 2026, the reference Level 2 pipeline: 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.
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.
The principle is that supply-chain security is enforced, not declared. The audit reality is that the levels claimed in security questionnaires are not the levels enforced in production pipelines. Closing that gap — control by control, with the deploy-time verification step wired in and actually blocking — is the work. Teams that do it will pass the assessments that are coming. Teams that do not will be explaining gaps when the CRA and FedRAMP Rev 5 timelines stop being aspirational.
FAQs
What's the realistic SLSA level for most enterprise pipelines in 2026?
Level 1 with manual sign-off. Provenance is generated by a marketplace action and signed if the team adopted Sigstore, but verification at deploy is almost never wired in and two-party review is usually advisory. The questionnaire claim is typically Level 2 or 3; the enforcement is Level 1 with documentation. Level 2 is genuinely achievable and is the right target for the next twelve months.
Why was SLSA Level 4 removed in v1.0?
The OpenSSF acknowledged the spec was over-specifying requirements (hermetic, reproducible builds, two-party review of all dependencies) for a market that had not reached Level 2 in volume. Vendor claims of "Level 4 readiness" have no current normative meaning in v1.0.
What's the single highest-leverage control to add to a typical CI/CD pipeline?
The deploy-time verification step. Wiring Sigstore policy-controller, Kyverno cosign policies, or OPA Gatekeeper into the Kubernetes admission controller in enforcing mode (not advisory) is the difference between producing evidence and enforcing a control.
Can we reach SLSA Level 3 on shared GitHub-hosted runners?
Not in the spec's strict reading. Level 3 requires isolation such that one build cannot influence another; shared hosted runners do not provide that property because workflows can in principle write to caches other workflows read from. Achieving Level 3 requires ephemeral runners, isolated infrastructure (Firecracker or Kata microVMs, single-tenant per build), or a build platform with stronger isolation guarantees.
How do we audit a vendor's SLSA claim during procurement?
Ask for one provenance JSON for an artifact that shipped in the last week and the verification policy that gates deploy on the provenance. Give the vendor 24 hours. A vendor at the claimed level can produce both within a working day. A vendor that produces marketing material, needs a week, or returns a partial answer is a vendor whose claim should be downgraded in the buyer's risk model.
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.