SLSA Framework — Vocabulary and Communication

SLSA (pronounced 'salsa', Google, now OpenSSF): a framework of increasingly rigorous supply chain security requirements, from SLSA 1 (basic documentation) to SLSA 4 (fully hermetic, reproducible builds with two-party review). It provides a common vocabulary and measurable levels for software build integrity.

Provenance attestation (SLSA): cryptographically signed metadata stating: this artifact was built from commit X at time Y using build system Z on runner W. Consumers can verify: was this artifact actually built from the source I audited? Was it built on a trusted build system? Has it been tampered with after build?

Hermetic build: the build process has no access to external network or mutable file system inputs — only the explicitly declared, pinned, verified dependencies. This prevents: downloading malicious packages during build, using different dependency versions on different runs, and other build-time injection attacks. Required for SLSA level 3+.

SLSA level 4 two-party review: no code may be committed without review by a different person. This prevents a single compromised or malicious developer from unilaterally introducing backdoors — the SolarWinds attack vector. Two-party review is a control against insider threats and compromised developer credentials.

Artifact signing (Sigstore/cosign, GPG): the build system signs the artifact with a private key. Consumers verify the signature using the public key before using the artifact. This detects tampering in transit (package registry compromise, man-in-the-middle) and impersonation (fake packages pretending to be from a trusted publisher).