SLSA Framework

The current highest fully-achievable level for most organizations. SLSA Build L3 requires that the build process runs on a hardened, isolated platform with strong tenant isolation. This prevents one build from influencing another. Key requirements include:

• Ephemeral and isolated build environments
• No network access to prevent exfiltration of secrets
• Hermetic builds that are fully defined and reproducible
• Output is a cryptographically signed in-toto attestation binding the artifact to its provenance

The core artifact of any SLSA-compliant pipeline is the non-falsifiable provenance. This metadata record describes how an artifact was produced, including the build recipe, source materials, and build environment. Provenance must be:

• Cryptographically signed by the build platform's private key
• Verifiable by any consumer using the platform's public key
• Generated as an in-toto attestation conforming to the SLSA v1.0 provenance schema This allows policy engines to answer the question: 'Should I trust this artifact?'

Before securing the build, you must secure the source. SLSA Source Level 2 requires:

• Version-controlled history with a strong, auditable retention policy
• Verified commit authorship using cryptographic signing (e.g., SSH or GPG keys)
• Branch protection rules preventing direct pushes to main
• Two-person review mandatory for all changes This establishes a chain of custody from the developer's intent to the source code ingested by the build system.

SLSA is not just a checklist; it's an automated enforcement mechanism. A policy engine consumes signed attestations and evaluates them against organizational policy. For example, a policy might state: 'Only allow deployment of container images built from the main branch on the trusted CI platform.' The engine cryptographically verifies the attestation's signature and checks the predicate fields. This decouples policy evaluation from the build process itself, enabling consistent, automated enforcement across heterogeneous environments.

SLSA Level 4 represents the ideal state of hermeticity and reproducibility. A build is hermetic if all transitive dependencies are declared and controlled. A build is reproducible if two independent builds from the same source produce a bit-for-bit identical output. While difficult to achieve universally, these properties enable:

• Verification summary attestations (VSA) that confirm an artifact meets a specific SLSA level
• Binary authorization where only verified artifacts pass through the deployment gate
• Defense against advanced supply chain attacks like the SolarWinds incident

A build process that is fully isolated from external network access and undeclared dependencies. SLSA Level 4 mandates hermeticity to eliminate trusted builder compromise vectors. A hermetic build guarantees that the output artifact is a deterministic function of only the declared source and build script, with no possibility of fetching poisoned dependencies mid-build.

• All inputs must be declared and verified by hash before the build starts
• Network access is blocked; any required dependency must be pre-fetched and cached
• Enables reproducible builds — two independent builders produce a bit-for-bit identical artifact

A build environment that is provisioned fresh for each build invocation and destroyed immediately after, leaving no mutable state between builds. This is a SLSA Level 3 requirement that prevents cross-build contamination where a previous build's compromised output or cached secrets could poison a subsequent artifact.

• Typically implemented using containerized runners or cloud VMs with no persistent volumes
• Prevents an attacker who compromises one build from persisting in the environment
• Combined with hermeticity, ensures the build is a pure function of the declared inputs