Supply Chain Levels for Software Artifacts (SLSA)

The cornerstone of SLSA. Provenance is a verifiable, cryptographically signed statement about how a software artifact was built. It answers 'who, what, where, and how' for the build process.

• Format: Uses the in-toto attestation framework with a SLSA-specific predicate.
• Contents: Includes builder ID, source repository, build invocation parameters, and all transitive dependencies.
• Key Distinction: Unlike a simple checksum, provenance links an artifact to its origin, enabling policy decisions based on the builder's trustworthiness.

SLSA defines ascending Build Levels (L0-L3) that represent increasing maturity and tamper-resistance of the build platform. Each level introduces specific requirements.

• L0: No guarantees. Binary is opaque.
• L1: Provenance is generated, showing how the software was built.
• L2: Build runs on a hosted service with source control, generating authenticated provenance.
• L3: Builds are hermetic and fully isolated. The build definition and output are verifiable and cannot be influenced by external parameters.

A hermetic build is a build process that is entirely self-contained, with no network access or hidden state. This is a mandatory requirement for SLSA Build Level 3.

• Determinism: The same source inputs always produce a bit-for-bit identical output.
• No Fetching: All dependencies must be declared and resolved before the build starts; no apt-get install or pip install during the build.
• Isolation: The build runs in an ephemeral, sandboxed environment that is destroyed after completion, preventing secret exfiltration or output tampering.

Provenance is only useful if it's verified. A policy engine evaluates signed attestations against organizational rules before an artifact is deployed.

• Policy-as-Code: Rules are written declaratively (e.g., 'Only allow containers built by our trusted CI system from the main branch').
• Integration Point: Typically enforced at the Admission Controller level in Kubernetes, blocking non-compliant deployments.
• Tooling: Projects like Open Policy Agent (OPA) and Kyverno are commonly used to codify and enforce SLSA-based deployment policies.

A VSA is a policy decision rendered as a signed attestation. It states that an artifact's SLSA provenance has been evaluated and meets a specific policy.

• Purpose: Simplifies downstream verification. A consumer can check the VSA instead of re-evaluating the full provenance chain.
• Workflow: A policy engine evaluates the SLSA provenance, and if it passes, it generates a VSA that is stored alongside the artifact.
• Efficiency: This decouples complex policy evaluation from deployment time, speeding up continuous delivery pipelines.

SLSA's security model extends to the source. Source Level requirements protect the integrity of the code before it even reaches the build system.

• Two-Person Review: Changes must be approved by a different authorized person.
• Verified History: The git history must be cryptographically signed and protected from force-pushes.
• Strong Authentication: Contributors must use multi-factor authentication to push code, preventing account takeover from injecting malicious source changes.