Organisations implement SLSA Level 3 by building on tamper-resistant provenance, isolated build environments, and controlled source and build identities. Use ephemeral builders, enforce authenticated, auditable build steps, and produce provenance that links source, builder, and artefact. Then verify that downstream systems reject artefacts without valid provenance.
What SLSA Level 3 Requires in Practice
slsa level 3 is about making builds hard to tamper with and easy to trust. Organisations need isolated, ephemeral build environments, authenticated build steps, and provenance that ties the source, the builder, and the artefact together. The goal is not just secure compilation, but a repeatable chain of custody that downstream systems can verify.
That usually means the build system itself becomes part of the control surface. A SLSA and Build Provenance Guide is useful because Level 3 is where provenance, hermeticity, and verification stop being abstract concepts and become operational requirements. In practice, teams need to know which build identities are allowed to sign, which steps must be isolated, and which artefacts are eligible for release.
Level 3 also changes how you think about trust in CI/CD. The CI/CD Pipeline Identity Security Guide is relevant because controlled build identities, short-lived tokens, and trusted publishing are what make provenance credible instead of decorative. If a pipeline can mint artefacts without strong identity and step control, the provenance record may still exist, but it will not meaningfully reduce supply-chain risk.
For organisations that build from third-party code, supply-chain integrity depends on more than the pipeline alone. The Open Source Security Guide matters because dependency hygiene, trusted publishing, and version pinning reduce the chance that a clean-looking build is assembled from compromised inputs. Level 3 works best when provenance is paired with disciplined source selection and dependency control.
How to Build the Control Set for Level 3
Start by separating three things: source integrity, build integrity, and release integrity. Source integrity means the code you intend to build is what enters the pipeline. Build integrity means the compilation environment is isolated, reproducible where possible, and not influenced by interactive human changes. Release integrity means the artefact that leaves the pipeline carries provenance that can be checked before deployment.
Controlled identities are central because SLSA Level 3 assumes the builder can be trusted only if its actions are attributable. That means no shared human logins for release steps, no ad hoc credentials in job logs, and no build process that depends on persistent secrets sitting on the machine. Ephemeral builders are preferred because they reduce the window for contamination and make each build easier to reason about.
Authenticated and auditable build steps are just as important as the environment itself. If a step can be modified without review, or if an artefact can be signed outside the approved path, provenance becomes less useful. The point of Level 3 is to make the release path observable enough that a downstream verifier can reject anything that did not follow the expected chain.
Verifying Provenance Before Release and Deployment
Implementing Level 3 is incomplete until verification becomes a gate, not an afterthought. Downstream systems should reject artefacts that do not have valid provenance, and they should verify that the provenance matches the expected source, builder, and build process before deployment or promotion.
This is where the policy detail matters. A provenance object is only useful if the consuming system checks it consistently and knows what acceptable provenance looks like for that artefact class. Organisations often get the build side mostly right, then weaken the control by allowing manual overrides, exception paths, or deployment systems that accept unsigned or unverified artefacts.
The operational check is simple: can you prove which source commit produced the artefact, which trusted builder created it, and whether the build happened under the intended controls? If the answer is unclear, the implementation is not yet at Level 3 even if the pipeline emits attestations.
Risk and Threat Considerations
Level 3 is mainly about reducing supply-chain tampering, but the residual risk is still meaningful if provenance can be forged, build identities are overexposed, or verification is inconsistently enforced. The most common failure mode is not total absence of controls, it is a gap between producing provenance and actually trusting it at deploy time.
Failure mechanism: Attackers or insiders exploit weak build isolation, long-lived credentials, or uncontrolled release steps to inject code, alter artefacts, or generate provenance that does not reflect the real build path.
Impact: A compromised build or release path can turn a trusted delivery pipeline into a high-value persistence and distribution channel, allowing malicious artefacts to reach production with an apparently valid chain of custody.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
SLSA, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| SLSA | Supply-chain Levels for Software Artifacts | SLSA Level 3 centers on build provenance, isolated builds, and verified artefact integrity. |
| Recommendation — Adopt Level 3 controls to produce and verify trusted provenance for every release artefact. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | Build and release systems rely on authenticated non-human build identities and trust relationships. |
| CM-3 — Configuration Change Control | Level 3 depends on controlled, reviewable build steps and restricted changes to pipeline behaviour. | |
| AU-10 — Non-repudiation | Provenance and auditable build steps support attribution of who or what produced the artefact. | |
| Recommendation — Authenticate build services and release systems with controlled, auditable machine identities. Place pipeline and build-step changes under formal change control before release. Retain audit evidence that ties each build and release action to an accountable identity. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | Secure build pipelines and provenance verification are part of protecting software delivery integrity. |
| Recommendation — Harden software delivery pipelines so only trusted artefacts can reach production. | ||
Practitioner Guidance
What to verify: Confirm that every release path enforces provenance checks automatically, not just in one deployment system. If any path can accept an artefact without validating the expected source, builder, and build recipe, treat that as a control failure.
Decision rule: If the build environment needs persistent state, broad credentials, or interactive human intervention to complete the release, it is too permissive for Level 3. Rework the pipeline so the default path is ephemeral, attributable, and non-interactive.
What good looks like: A release artefact can be traced back to a specific source revision and trusted builder, and the deployment platform rejects anything missing the required provenance or produced outside the approved build path.
Practitioner takeaway: SLSA Level 3 is achieved when provenance becomes enforceable policy, not just metadata, and when build identities, isolation, and verification all fail closed together.
Related resources from NHI Mgmt Group
- How should organisations implement the NIST Cybersecurity Framework 2.0 to turn high-level guidance into real risk reduction?
- How should organisations implement transaction-level authentication in paperless workflows without creating unnecessary friction for users?
- How do organisations implement the PII confidentiality impact level?
- How do organisations implement CMMC Level 3?