↓ Skip to main content
Le Site de François
  1. Index/

SLSA (Supply-chain Levels for Software Artifacts)

Supply-Chain Security Provenance Attestation Build Openssf

SLSA (Supply-chain Levels for Software Artifacts), pronounced “salsa”, is a security framework published by OpenSSF (originally proposed by Google in 2021, version 1.0 released April 2023) that defines progressively stronger requirements for build integrity and provenance — the verifiable record of where a software artifact came from, what source it was built from, how it was built, and what the build environment looked like. The motivating threat is supply chain attacks like SolarWinds (malicious code injected into the build system) and XZ Utils (malicious code injected into the source repository): in both cases the artifact that reached users was not what the source code claimed, and consumers had no way to verify the discrepancy. SLSA’s answer is a provenance attestation: a signed, machine-readable document produced by the build platform that records the source repository and commit, the build instructions, the builder’s identity, the build environment’s properties, and the digest of the resulting artifact. Signed provenance is the basis on which consumers can make automated trust decisions rather than relying on reputation or manual inspection.

SLSA is organised into tracks; the most commonly cited is the Build track, which in the latest published SLSA specification (v1.2) defines Build Levels 1–3 with progressively stronger guarantees. SLSA Build Level 1 requires that the build process be fully scripted (no manual steps) and that provenance be generated and available, but it does not require strong authenticity guarantees — its value is documentation and process hygiene, not tamper evidence. SLSA Build Level 2 requires provenance to be authenticated by the build platform (not the developer), produced automatically as a non-forgeable output of a hosted build service rather than a developer’s local environment; this prevents a developer from falsely claiming a package was built from a specific commit when it was not, but the build platform itself could still be compromised. SLSA Build Level 3 adds stronger protections around the build environment and provenance generation (isolation and hardening expectations for the build platform), making it the practical target for many production systems. Some earlier descriptions of SLSA mention “Build Level 4” requirements (two-person review, reproducible builds, dependency completeness); in current SLSA v1.x those are not part of the released Build-level requirements and are discussed as future work in the SLSA community.

SLSA provenance documents use the in-toto Attestation Framework (ITE-6) format: a JSON envelope with a statement (subject identifying the artifact by digest, predicateType identifying the predicate schema, and predicate containing the provenance details) wrapped in a DSSE (Dead Simple Signing Envelope) that carries the signature and the signer’s key identity. For OCI artifacts, provenance attestations are stored as OCI referrers alongside the image they describe, signed with Sigstore cosign, and discoverable via the referrers API — so a verifier that fetches a container image can also fetch and verify its SLSA provenance in a single registry interaction. Native SLSA provenance generation is built into GitHub Actions (via the slsa-framework/slsa-github-generator reusable workflow, which generates Level 3 provenance signed by GitHub’s OIDC identity), Google Cloud Build, and Tekton Chains. Kubernetes admission controllers and policy engines (Kyverno, OPA Gatekeeper, Sigstore Policy Controller) can enforce SLSA level requirements as deployment gates: a policy might require that all production images carry a valid Level 3 provenance attestation from a CI system in the organisation’s GitHub organisation, with the source repository and build workflow matching an allowlist. The combination of SBOM (what is in the artifact), VEX (which vulnerabilities in the SBOM are exploitable), and SLSA provenance (how and where the artifact was built) forms the complete supply chain metadata set that ORAS manages and OCI referrers distributes — collectively providing the evidence base for automated, policy-driven software supply chain governance at scale.

Related

Confidential Cluster

Security Confidential-Computing Kubernetes Attestation Tee
A Confidential Cluster is a Kubernetes cluster designed so that the cloud or infrastructure operator — including hypervisor administrators, datacenter staff, and anyone who can access the underlying hardware — is entirely outside the trusted computing base. It achieves this by running every Kubernetes node, including control plane nodes, as a Confidential VM, and by extending the confidential boundary to cover not just individual workloads but the cluster’s network traffic, persistent storage, and control plane state. The goal is that a workload owner can cryptographically verify the entire cluster before trusting it, and that no privileged party outside the cluster’s own CVMs can read or tamper with workload data, cluster secrets, or etcd contents.

Confidential Containers (CoCo)

Security Confidential-Computing Kubernetes Attestation Containers Cncf
Confidential Containers (CoCo) is a CNCF sandbox project that lifts hardware confidential computing — TDX, SEV-SNP, Intel SGX, IBM Secure Execution — up to the Kubernetes pod level, providing a unified software layer that abstracts away the underlying TEE technology. Its defining trust model is unusually strict: the Kubernetes control plane, the kubelet, the container runtime, and the cloud operator are all treated as explicitly untrusted. Only the hardware itself and the workload owner’s own supply chain are in scope for trust.

Confidential GPU

Security Confidential-Computing Gpu Ai Attestation Nvidia
A Confidential GPU is a GPU whose memory, computation state, and data transfers are hardware-encrypted and isolated from the host system — extending the Trusted Execution Environment (TEE) boundary that technologies like TDX and SEV-SNP provide at the CPU level to encompass the GPU accelerator as well. The primary implementation today is NVIDIA Confidential Computing on the Hopper architecture (H100 and later), which encrypts all data resident in GPU High Bandwidth Memory (HBM) using per-context keys managed by the GPU’s on-die security processor. This means that model weights, training data, activations, and intermediate computations are cryptographically protected throughout GPU processing — a host administrator, hypervisor, or co-tenant with DMA access to the PCIe bus sees only ciphertext. The GPU also participates in a dedicated attestation flow: the NVIDIA Remote Attestation Service (NRAS) produces signed evidence that a specific GPU is genuine NVIDIA hardware running in Confidential Computing mode with unmodified firmware, analogous to how Intel DCAP or AMD KDS attest CPU TEEs. This GPU attestation is verified alongside CPU attestation before secrets (model decryption keys, dataset credentials) are released to the combined CPU+GPU TEE. The technology requires no application code changes — existing TensorFlow, PyTorch, and CUDA workloads run unmodified inside the confidential boundary. The primary threat model is the same as CPU-level confidential computing (protecting data-in-use from the infrastructure operator) but applied to the specific risk of AI workloads: model intellectual property theft, training data exfiltration, and inference input/output interception during GPU computation.