SLSA Level 3 sits at the awkward but consequential middle of the framework: high enough to demand a hosted build platform with non-falsifiable provenance, low enough to be achievable by most engineering organizations without rewriting the world. The teams that have reached it consistently report the same thing, that the bulk of the work was unglamorous plumbing rather than novel cryptography, and that the resulting build pipeline is materially easier to reason about.
This post lays out a blueprint that has held up across several rollouts in 2026. It assumes you are starting from a typical GitHub Actions or GitLab CI setup, and that you have a meaningful number of build pipelines rather than a single greenfield service.
What does SLSA L3 actually require?
The L3 requirements collapse to four concrete claims. The build runs on a hosted build platform, not a developer laptop or a long-lived VM. The provenance is generated by the build platform itself, not by the user-controlled portion of the build script. The provenance is non-falsifiable, meaning a user cannot tamper with it after the fact or fabricate it for an unrelated artifact. And the provenance is signed and made available to consumers in a verifiable form.
The non-falsifiability requirement is the load-bearing one. It is what distinguishes L3 from L2 and what eliminates a large class of supply chain attacks where an attacker who compromises the build script also gets to write the provenance that vouches for the resulting artifact. Reaching this requires that some component outside the user-controlled script signs the provenance with a key the user cannot access during the build.
How do hosted builders fit in?
The cleanest path to L3 in 2026 is to use a hosted SLSA builder rather than rolling your own. The slsa-github-generator project, GitLab's built-in SLSA provenance integration, and the equivalents in Buildkite and CircleCI all produce L3-conformant provenance with minimal user configuration. The hosted builder runs in a separate trust boundary from your build steps, observes the build, and signs the resulting provenance with a key that your workflow cannot touch.
The trade-off is that you cede some flexibility. Hosted builders are opinionated about how artifacts are produced, what metadata they capture, and what signing identity they use. For most language ecosystems this is fine, but if your build does anything unusual, multi-stage cross-compilation, embedded firmware signing, complex monorepo subset builds, you will hit edges. The right response is almost always to refactor the build to fit the hosted builder, not to roll your own and lose the trust separation.
What does the provenance document look like?
L3 provenance follows the in-toto attestation framework, with a predicate type of slsa-provenance v1 or later. The predicate captures the builder identity, the build type, the resolved invocation, the materials consumed including their hashes, and the byproducts produced. The subject is the artifact being attested, identified by content hash. The whole document is wrapped in a DSSE envelope and signed by the builder's identity, with the signature recorded in Rekor or an equivalent transparency log.
The materials section is where most of the verification value sits. A complete materials list lets a downstream verifier check that the build consumed only sources from the expected repository at the expected commit, with the expected dependency lock file, and nothing else. Materials hygiene is also where most teams have to invest effort. Lock files must be deterministic, dependency caches must not bypass the provenance capture, and any out-of-band downloads in build scripts will show up as missing materials or, worse, as a hole in the supply chain story.
How do you verify provenance in CD?
Generating provenance is half the work; verifying it before deployment is the other half. The standard pattern is a verification gate in the deployment pipeline that takes the artifact, fetches its provenance from the registry or transparency log, validates the signature against the expected builder identity, and checks policy claims: that the source repository matches, that the builder was invoked on the expected workflow, that the materials list does not contain unexpected dependencies.
The policy language has converged on Rego via OPA or the equivalent in Kyverno for Kubernetes admission, and slsa-verifier remains the reference implementation for the verification step itself. The gate should fail closed: if provenance cannot be fetched, if the signature is invalid, if the builder identity does not match, the deployment does not happen. Most outages during rollout come from policy that is too strict in edge cases like rebuilds from cache or retried jobs; budget time to tune these.
How do you handle long-tail builds?
Every organization has a long tail of builds that resist easy L3 conformance: legacy Jenkins pipelines, machine images built by Packer, firmware artifacts built on isolated hardware, vendor-supplied binaries that you republish. The pragmatic approach is to score these explicitly. A build that is L3 conformant gets a green mark and full automated trust. A build that is L2 or below gets a documented exception, a remediation owner, and a deadline. A build that produces something you ship to customers without any provenance at all gets flagged as a release blocker.
The point of the framework is not that every artifact reaches L3 on day one. The point is that you know which artifacts have which provenance posture, and you can make risk-informed decisions about deployment, customer attestations, and prioritization of remediation work.
How Safeguard Helps
Safeguard ingests SLSA provenance alongside SBOMs and treats both as evidence in the same supply chain inventory. Every artifact ingested is scored against the SLSA framework, with the level surfaced explicitly and the gaps documented. Griffin AI correlates provenance with reachability and CVE findings, so a vulnerable component with weak provenance is prioritized higher than the same component built by a verified L3 pipeline. Policy gates enforce minimum provenance levels at deployment time, integrating with cosign verify and slsa-verifier so you do not have to rebuild the verification stack. Our TPRM scoring incorporates supplier SLSA posture, and zero-CVE base images ship with L3 provenance by default.