SLSA Framework

SLSA defines an ascending scale of security rigor, from basic build scripting to hermetic, two-person reviewed builds.

• Level 1: Build is fully scripted/automated with provenance generation.
• Level 2: Uses version control and a hosted build service generating authenticated provenance.
• Level 3: Source and build platforms meet auditability standards; builds are isolated.
• Level 4: Requires two-person review of all changes and hermetic, reproducible builds.

SLSA v1.0 decouples security into independent tracks to allow incremental adoption. Each track has its own level progression.

• Build Track: Focuses on build platform hardening, isolated builds, and parameterless recipes.
• Source Track: Secures the source control system, requiring strong authentication, branch protection, and two-person review at higher levels.
• Dependencies Track: Addresses the availability and integrity of third-party dependencies through hashed, verifiable resolution.

A core output of SLSA compliance is a cryptographically signed provenance attestation—a verifiable metadata document describing how an artifact was produced.

• Follows the in-toto attestation specification.
• Binds the artifact hash to the build recipe, source repository, and builder identity.
• Enables policy engines to automatically reject artifacts lacking valid, expected provenance before deployment.

A hermetic build is one executed in complete isolation, with no network access and all inputs explicitly declared.

• Required for SLSA Build Level 3+.
• Prevents a compromised build service from fetching malicious dependencies mid-build.
• Ensures the build is fully deterministic and auditable, as every input is hashed and recorded in the provenance.

SLSA attestations are machine-readable, enabling automated policy enforcement at deploy time using tools like Open Policy Agent (OPA) or Binary Authorization.

• Policies can require a minimum SLSA level for production deployments.
• Rejects artifacts with missing, invalid, or tampered provenance.
• Transforms supply chain security from a manual audit into a continuous, automated gate.

SLSA directly addresses critical supply chain attack vectors identified in high-profile compromises.

• Source Tampering (A): Unauthorized commits to protected branches.
• Build Tampering (B): Compromised CI/CD pipelines injecting malicious code.
• Dependency Confusion (C): Resolving a malicious package instead of the intended internal one.
• Artifact Substitution (D): Swapping a legitimate artifact for a backdoored version post-build.

A supply chain attack where a malicious package with a higher version number is uploaded to a public registry, tricking a build system into downloading it instead of the intended private dependency. SLSA mitigates this by requiring explicit dependency pinning and hermetic builds that isolate the build environment from public registries.

• Attack vector: Misconfigured package managers checking public registries first
• Defense: Digest pinning, scoped registries, vendor mirroring
• Real-world impact: 35+ major companies compromised in 2021