SLSA: A Route to Tamper-Proof Builds and Secure Software Provenance
SLSA (Supply-chain Levels for Software Artifacts, pronounced ‘salsa’) is a progressive, industry-backed software security framework that safeguards software integrity throughout the development and delivery lifecycle.
SLSA adoption is ramping up in industries where trust isn’t optional. As dependencies proliferate and threats multiply, SLSA provides a solid, structured path to prove that software is secure by design. SLSA isn’t a box-ticking exercise; it’s about building systems and artifacts that are tamper-resistant and trustworthy by default.
History of SLSA
Introduced in 2021, SLSA was built by a cross-industry consortium led by Google in collaboration with the Open Source Security Foundation (OpenSSF), operating under the Linux Foundation. By harvesting cross-industry expertise, SLSA was designed to establish a standardised framework for securing the software supply chain based on real-world threats and security gaps.
SLSA development directly responded to high-profile software supply chain attacks and growing concerns over software integrity and provenance. The SolarWinds compromise, Codecov Bash Uploader breach, and Linux hypocrite commits exposed critical infrastructure vulnerabilities by tampering with build processes and injecting malicious code into trusted software.
Since its initial release, SLSA has evolved significantly, particularly with the formal emergence of its four security levels. As a vendor-neutral security framework, SLSA continues refining its standards through industry collaboration. It is gaining momentum across industries striving to enhance software supply chain security. While not yet universally adopted, it is rapidly becoming a benchmark for compliance and cybersecurity best practices.
Progressive Security with SLSA
SLSA is progressive in that it defines a series of levels of increasing supply chain security guarantees. Version 0.1 of the spec defined four conformance levels according to three critical domains: build, source, and dependencies.
Version 1.0 revised the approach, focusing the evaluation of each domain into a separate track, and provided a framework for the ‘build’ track. Domain-based tracks can measure progress in a particular security aspect without blocking an unrelated aspect.
The build track concentrates on the provenance of an artifact and has four levels aimed at verifying artifact integrity:
- SLSA Build Level 0 (“None”): No security controls.
- SLSA Build Level 1 (“Provenance Exists”): Provenance only, describing how the package was built. The focus here is on the manual detection of mistakes and having documentation in place.
- SLSA Build Level 2 (“Hosted Build Platform” ): The host platform signs and generates the provenance. The focus is on detecting (and preventing) tampering after the build.
- SLSA Build Level 3 (“Hardened Builds”): Ensuring a hardened build platform. This level focuses on detecting (and preventing) tampering during the build process.
The build track aims to ensure that every software artifact is built in a secure, auditable, and tamper-resistant environment. A fundamental pillar of software supply chain security.
SLSA Levels and Their Implications
SLSA Build Track Level 1: Laying the Foundations
According to SLSA, level 1 is the first step in securing your software supply chain. It requires builds to produce provenance metadata, such as details on what was built, how, by whom, and on what platform. While this doesn’t guard against tamper resistance, it introduces vital transparency. With provenance, you reduce the risk of release errors and gain visibility across teams to build an inventory of software components and build platforms.
Implementing level 1 is relatively straightforward. Most CI/CD systems can be configured to generate provenance in standard formats such as SPDX or CycloneDX. Adding this process enhances accountability and visibility without a heavy lift, making it a practical starting point for software supply chain security.
Cloud-native systems assist in level 1 conformance by automatically storing and serving artifacts with attached metadata and provenance, providing the required visibility of what and how the artifact was built.
SLSA Build Track Level 2: Establishing Trust with a Hosted Build Platform
Level 2 advances software supply chain security by ensuring that builds happen on trusted, dedicated infrastructure such as Google Cloud Build or GitHub Actions, not on a developer’s local machine. This deters casual tampering and mitigates risk from insider threats or attackers who face legal or financial consequences. Provenance is digitally signed and tied to the build platform, so it’s harder to fake or manipulate artifacts without an intentional, traceable attack.
To meet level 2, the organisation must use a hosted build system that automatically generates and signs provenance. Downstream customers must also verify the authenticity of that provenance. Level 2 enables teams to migrate to more secure, auditable build platforms. It strengthens release integrity and offers a practical implementation for large-scale adoption.
Cloud-native artifact management systems offer a hosted build platform that generates signed provenance and ensures a secure and reliable way to store and distribute artifacts. Valuable integrations with standard CI/CD tools like CircleCI, GitHub Actions, and Google Cloud Build make it easier to ensure that artifacts and their metadata are stored securely, verified on upload, and distributed globally quickly and securely.
SLSA Build Track Level 3: Hardening Builds Against Tamper Resistance
Building on the previous levels, Level 3 significantly strengthens build pipeline security. It ensures that provenance cannot be forged or bypassed without a serious exploit, blocking the efforts of most adversaries.
The build process runs on a hardened platform with isolation and tamper protection, helping to defend against insider threats and compromised credentials. This level is an ideal aspiration for most organisations, as it balances confidence in security and implementation overhead.
Level 3 needs a secure build environment that strictly isolates the build process and protects signing material. The build must run without any opportunity to interfere with other build processes. Perhaps in a tailor-made container or VM.
SLSA level 3 requires strong protection during the build process. A good cloud-native artifact management platform supports this by working with established, hardened CI systems, enforcing strict build isolation, and securely storing signed provenance. Cloud-native has built-in access control, environment separation, and trusted delivery. Helping to ensure that every software artifact is authentic and tamper-free.
Cloud-Native and SLSA Compliance
Achieving SLSA compliance requires strong provenance, integrity guarantees, and a secure, verifiable software supply chain. While cloud-native registries inherently align with these requirements, self-managed or on-premises registries introduce risks that may compromise compliance—especially at SLSA Build Level 2, which mandates a separation between CI/CD and artifact distribution.
Cloud-native artifact management platforms offer several advantages that directly support SLSA compliance:
- Built-in Provenance and Immutability – Cloud-native registries natively support provenance metadata and artifact immutability, ensuring tamper-resistant storage.
- Automated Signing and Access Controls – Enforced signing and fine-grained access policies prevent unauthorized modifications, while audit logs provide verifiable tracking of all changes.
- End-to-End Traceability – Full visibility across builds and releases enables transparent tracking of software artifacts, a cornerstone of SLSA’s integrity and provenance standards.
- Scalability and Global Reliability – Enterprise-grade cloud-native platforms dynamically scale to worldwide demand, ensuring reliable artifact distribution while maintaining security and compliance.
Choosing a cloud-native registry directly simplifies and strengthens SLSA compliance by leveraging built-in capabilities around the core reproducibility, integrity, and security requirements.
Practical Challenges for Non-Cloud Solutions
Attempting to achieve SLSA compliance with on-premises or bespoke solutions introduces significant challenges, including:
- Increased Risk of Human Error – Manual artifact handling raises the chances of accidental modifications or tampering.
- Security and Compliance Gaps – Self-hosted registries lack built-in immutability guarantees, increasing the risk of provenance loss or unauthorized changes.
- Scalability and Consistency Issues – Managing distributed storage across multiple regions is complex, often leading to inconsistent security postures and availability risks.
- Lack of Automated Provenance - Without native support for signed metadata and verification, guaranteeing artifact authenticity becomes harder and error-prone.
- Poor Separation of Concerns - On-prem solutions can blur the boundary between developer access and infrastructure control, potentially exposing critical build processes to risk.
The last point highlights a key failing of non-cloud solutions - they struggle to separate concerns, which is a much more dangerous approach. A hosted environment can solve what should be a minimum requirement.
For organizations aiming to meet SLSA’s security requirements, adopting a cloud-native registry is a much safer choice.
See Also
Accelerate Your Path to SLSA Compliance with Cloudsmith
Liked this article? Don\'t be selfish (:-), share with others: Tweet