Implement SLSA Level 4 in 2026 pipelines with hermetic builds and automated provenance. Master supply chain security for modern dev workflows. Read now.
What SLSA Level 4 Demands of Your Pipeline
SLSA Level 4 is the highest bar in the Supply-chain Levels for Software Artifacts model. It requires that builds run in a controlled, isolated environment, that the process is fully scripted and repeatable, and that every artifact ships with machine-readable provenance that ties the binary back to its source, dependencies, and build steps. In practice that means your CI system must not only compile code—it must prove, cryptographically and automatically, how that code was produced.
Level 4 is not a checkbox on a compliance form. It is a set of constraints on how you fetch inputs, how you isolate the build worker, and how you record what happened. If any step depends on an operator’s laptop, an ad hoc script, or an unsigned intermediate, you are not at Level 4. The goal is simple: a consumer of your artifact should be able to verify that it came from the intended source under the intended rules, without trusting anyone’s word.
Hermetic Builds as the Non-Negotiable Core
A hermetic build is one that uses only declared inputs. The worker starts clean, pulls exactly the sources and dependencies you listed, and produces the same output bit-for-bit when those inputs do not change. Network access during the build is either blocked or limited to pinned, verified endpoints. Toolchains are fixed by hash or content address, not by “latest” tags. Environment variables and system packages that can change results are either frozen or removed from the equation.
To get there in a modern pipeline, treat the build definition as code: a single entrypoint that lists every input, every tool version, and every flag. Prefer content-addressed caches and lockfiles so dependency resolution is deterministic. Run builds in ephemeral, isolated runners that cannot retain state between jobs. When hermeticity fails—flaky network mirrors, unpinned base images, host-installed compilers—the provenance you generate later will describe a process you cannot replay, which defeats Level 4.
Automated Provenance Generation and Verification
Provenance is structured metadata that records who started the build, which source commit was used, which builder identity ran it, and which parameters were applied. At Level 4 this record must be generated by the build platform itself, not hand-written after the fact, and it must be signed so consumers can detect tampering. Automation is essential: every successful build emits provenance; every release path rejects artifacts that lack valid, matching provenance.
- Emit provenance at the moment of build completion, bound to the artifact hash.
- Sign with a key or identity controlled by the build service, not by individual developers.
- Store provenance next to the artifact and in a durable log so audits do not depend on a single bucket.
- In deploy and dependency-install paths, verify signature, builder identity, and source match before accepting the artifact.
Wire verification into the same gates you already use for tests and policy checks. If provenance is optional, it will be skipped under deadline pressure. Make invalid or missing provenance a hard failure for production promotion.
Fitting Level 4 into Everyday Dev Workflows
Developers should not need a separate security ritual to ship safely. Keep local development fast with non-hermetic or lightly isolated builds, and reserve full Level 4 constraints for the shared CI path that produces release candidates. Document the build entrypoint so engineers can reproduce CI failures locally where possible. Surface provenance and policy failures in the same pull-request checks they already watch, with clear messages about which input drifted or which builder identity was unexpected.
Start by locking down the release pipeline for one critical artifact: hermetic definition, isolated runner, automatic signed provenance, and verification at the point of deploy. Expand that pattern to libraries and secondary services once the path is boring and reliable. Level 4 is won by making the secure path the default path—not by adding manual steps that teams will work around when schedules tighten.