SLSA Provenance

Provenance is a signed attestation that captures the complete build recipe: source repository, build commands, environment variables, and entry point. Unlike simple digests, it records how the artifact was created, not just what it is. This metadata is generated by a trusted build service and stored alongside the image in an OCI-compliant registry.

• Records the exact Git commit SHA and repository URL
• Captures the builder's identity and trusted execution environment
• Prevents post-hoc tampering with build history

The framework defines ascending levels of security rigor, from L0 (no guarantees) to L3 (auditable, hardened builds). Each level adds concrete technical requirements.

• L1: Provenance exists but is not verified; builds are not isolated
• L2: Builds run on a hosted service with signed provenance
• L3: Builds are fully hermetic and isolated, with auditable control plane access
• L4: Two-person review of all changes and reproducible builds (draft)

The in-toto framework provides the standardized metadata format and layout specification that SLSA provenance uses to express supply chain integrity. It defines a verifiable record of each step in the software lifecycle.

• Uses link metadata to cryptographically record each action performed during the build
• Defines layouts that specify the required steps and functionaries for a compliant pipeline
• Enables verification that all steps were executed by authorized identities in the correct order
• Forms the attestation layer that SLSA builds upon for its provenance predicates

SLSA Build Level 3 represents the highest tier of build integrity within the SLSA framework, requiring fully auditable, non-falsifiable provenance. It mandates that builds occur on hardened, ephemeral platforms with no persistent access for human operators.

• Requires hermetic builds with no network access to prevent dependency confusion attacks
• Demands parameterless build configurations that cannot be altered by external inputs
• Enforces isolated build environments that are destroyed after each execution
• Generates non-forgeable provenance that auditors can cryptographically verify independently

Rekor is the immutable, append-only transparency log component of the Sigstore ecosystem. It records cryptographically signed entries of provenance attestations, making them publicly auditable and impossible to backdate or delete.

• Stores Merkle tree hashes of every signed attestation for tamper-evident verification
• Provides a global witness that a specific attestation existed at a specific point in time
• Enables monitoring for unauthorized or unexpected signing events in the supply chain
• Integrates directly with Cosign to automatically record image signatures and attestations

The Dead Simple Signing Envelope (DSSE) is a lightweight, context-agnostic wrapper for signing arbitrary payloads, including SLSA provenance attestations. It standardizes how signatures bind to their payloads across different signing schemes.

• Wraps a payload and payloadType with one or more cryptographic signatures
• Supports multi-signature scenarios where multiple authorities attest to the same artifact
• Uses a pre-authentication encoding (PAE) to prevent signature confusion attacks
• Adopted as the standard envelope for in-toto attestations and SLSA provenance documents

Binary Authorization is a deploy-time control that integrates with Kubernetes admission controllers to enforce SLSA provenance verification. It ensures only images with valid, policy-compliant attestations can be deployed to production clusters.

• Validates that the build provenance matches a trusted pipeline identity before admitting pods
• Enforces attestor-based policies that require specific signers or vulnerability scan results
• Integrates with Sigstore to continuously verify short-lived signing certificates
• Blocks deployment of images lacking required attestations, preventing supply chain attacks at runtime

A Vulnerability Exploitability eXchange (VEX) document is a companion attestation to SLSA provenance that communicates the exploitability status of known vulnerabilities within a specific artifact. It prevents false-positive security alerts from blocking deployment.

• Declares whether a CVE is affected, not affected, or under investigation for a specific product
• Stored alongside SLSA provenance as an in-toto attestation in the OCI registry
• Enables automated policy engines to suppress irrelevant vulnerability alerts during admission control
• Defined by the CSAF standard to ensure machine-readable, interoperable vulnerability statements