Supply-Chain — Google and OpenSSF Introduce SLSA Framework

On 21 June 2021 Google and the Open Source Security Foundation (OpenSSF) introduced the Supply-chain Levels for Software Artifacts (SLSA) framework. SLSA establishes four assurance levels that cover source controls, build system hardening, and tamper-evident provenance so teams can mitigate supply-chain compromise risks exposed by attacks such as SolarWinds and dependency hijacking.

Framework Highlights and Maturity Levels

SLSA provides a progressive security framework designed to help organizations incrementally improve their software supply chain integrity. The four-level structure allows teams to adopt improvements iteratively while maintaining development velocity.

• leveled maturity. SLSA provides a staged roadmap from SLSA 1 (build provenance) through SLSA 4 (hermetic builds with two-person review) that teams can adopt iteratively. Each level builds upon the previous, creating a clear progression path from basic artifact tracking to full supply chain security.
• Provenance attestation. Build systems must emit signed metadata describing source revisions, dependencies, and builders, enabling downstream verification. These attestations create an auditable record of exactly how each artifact was produced, making it possible to detect tampering or unauthorized modifications.
• Open reference tooling. The initiative released reference setups and policy templates developers can adopt inside existing CI/CD platforms. This tooling lowers the barrier to adoption by providing ready-to-use components rather than requiring organizations to build everything from scratch.

Understanding SLSA Levels in Detail

SLSA Level 1 focuses on documentation, requiring that builds produce provenance showing what process created the artifact. This baseline level helps organizations understand their current build processes and creates the foundation for more advanced protections. Level 2 adds hosted build requirements, ensuring builds occur on trusted infrastructure rather than developer workstations where security controls may vary.

Level 3 introduces source integrity requirements, mandating that source code comes from version control with change history and that builds use hardened build services. This level addresses insider threat scenarios and ensures that unauthorized code changes cannot bypass review processes. Level 4 represents the highest assurance, requiring hermetic builds that are fully reproducible and two-person review of all changes, providing maximum confidence that artifacts represent exactly what developers intended.

Implementation Guidance for Organizations

• Assess current posture. Inventory build pipelines, artifact repositories, and release processes to determine baseline alignment with SLSA requirements. This assessment identifies gaps and helps focus on improvement efforts based on risk and feasibility.
• Adopt provenance standards. Pilot Sigstore Fulcio/Rekor or in-house certificate authorities to sign artifacts and store tamper-resistant logs. Sigstore provides free, open infrastructure that reduces the cost and complexity of implementing artifact signing.
• Map to compliance controls. Link SLSA practices to SOC 2 CC8, FedRAMP SA-12, and ISO/IEC 27001 A.14 requirements covering code integrity and change management. This mapping helps justify SLSA investments to compliance teams and avoids duplicating security controls.

Enablement and Organizational Adoption

• Educate development, release engineering, and security champions on SLSA levels, highlighting quick wins such as version-controlled builds and reproducibility. Champions can help spread adoption across teams and answer questions from peers.
• Work with procurement to request SLSA attestations from critical software suppliers. Including SLSA requirements in vendor assessments extends supply chain protections beyond internally developed software.
• Embed SLSA checkpoints into internal SDLC policies, ensuring releases cannot proceed without signed provenance records. Policy enforcement prevents regression and ensures consistent application of supply chain protections.

Connection to Recent Supply Chain Attacks

The SLSA framework directly addresses vulnerabilities exposed by major supply chain incidents. The SolarWinds attack showed how compromised build systems could inject malicious code that passed code review because reviewers only examined source, not build outputs. SLSA Level 3 and 4 requirements specifically address this attack vector by requiring build system hardening and provenance that links artifacts back to reviewed source code.

Dependency confusion and typosquatting attacks exploit weak verification of package origins. SLSA provenance attestations provide cryptographic evidence of where packages came from and how they were built, enabling automated verification that downloaded dependencies match expected sources. Organizations implementing SLSA can detect and reject packages that lack proper attestations or claim origins that do not match their signatures.