Supply Chain Levels for Software Artifacts (SLSA)

The first level of build security requires that the build process occur in an ephemeral and isolated environment. This means each build invocation runs in a fresh, temporary context—such as a container or VM—that is destroyed after completion. The environment must not share state with previous or concurrent builds. This control prevents contamination from compromised build workers and ensures that a successful build is not the result of cached, unversioned, or malicious state from a prior run.

A hermetic build is one that has no network access and whose behavior is fully determined by its declared, immutable inputs. All dependencies, including compilers, libraries, and toolchains, must be fetched and verified before the build starts. No arbitrary network requests are permitted during execution. This guarantees that the build is reproducible and immune to dependency confusion attacks, where a package manager is tricked into downloading a malicious package with a similar name from a public registry.

The highest level of build security requires a hardened build platform that enforces tamper-proof provenance generation. The platform itself must be a trusted system that cryptographically signs the provenance attestation immediately upon build completion, using a key managed in secure hardware. Crucially, the build process cannot influence the contents of the provenance, preventing a compromised build from forging its own attestation. This is typically achieved through a trusted control plane that observes the build and generates the attestation independently.

SLSA extends security requirements to the source code itself. Source integrity controls mandate that code changes undergo a two-person review process and that the full history is stored in a verifiable, tamper-evident version control system like Git. The specific commit and repository must be recorded in the build provenance. This prevents threat actors from injecting malicious code through un-reviewed pull requests or by directly manipulating the source repository's history to hide their tracks.

The consumer-side component that enforces organizational policy by validating SLSA provenance before an artifact is deployed. A verification engine checks the cryptographic signature on the attestation, confirms the builder's identity against a trusted root, and evaluates the recorded inputs against a set of allowed source repositories and build parameters. This allows a DevSecOps team to codify a rule like, 'Only deploy containers built by our trusted CI platform from the main branch of the production repository.'

A build process that is fully self-contained and isolated from external network access, ensuring that all inputs are declared and verified before execution. Hermeticity is a requirement for SLSA Level 4.

• No network access during the build step
• All dependencies must be fetched and verified in a separate, audited resolution phase
• Reproducibility: The same inputs always produce a bit-for-bit identical output

A short-lived, disposable execution context created from a known-good, immutable image and completely destroyed after a single build task. This prevents state contamination between builds and is a prerequisite for achieving SLSA Level 3.

• No persistent state between build invocations
• Prevents credential leakage and build cache poisoning
• Common implementations: GitHub Actions ephemeral runners, Tekton Pipelines with fresh pods

A procedural control requiring that every change to the source code be reviewed and approved by a different authorized person before it can be merged. This is a mandatory requirement for SLSA Level 3 to prevent a single compromised account from injecting malicious code.

• Enforced via branch protection rules in GitHub, GitLab, or Gerrit
• Prevents insider threats and account takeover attacks
• Audit trail: All reviews are logged and non-repudiable