SLSA (pronounced “salsa”) is a vendor-neutral framework for verifying how software artifacts are built and whether they have been tampered with. Short for Supply-chain Levels for Software Artifacts, it defines a set of standards that build systems must meet to produce verifiable, trustworthy outputs.
SLSA is a consensus-based, cross-industry effort that gives security and development teams a shared vocabulary for supply chain security. Its core goals are to prevent tampering during the build process, maintain artifact integrity, and safeguard build environments.
Originally proposed by Google in 2021 and now maintained by the Open Source Security Foundation (OpenSSF), SLSA is designed as an open framework rather than a proprietary tool, allowing organizations to adopt its requirements using their existing tooling and workflows.
Why is the SLSA framework needed?
High-profile supply chain attacks have shown how vulnerable the software supply chain has become.
SolarWinds (2020): Malicious updates were distributed to over 18,000 organizations, including U.S. government agencies.
JetBrains (2020): Administrative access to CI/CD servers was enabled through compromised build infrastructure.
Okta (2023): Customer session tokens were exposed through a support system vulnerability.
In each case, the compromise occurred in the systems responsible for building or distributing software rather than the application code itself.
These incidents highlight a consistent pattern: attackers exploit the gap between code commit and artifact deployment. Software supply chains rely on shared dependencies, build systems, and distribution pipelines, which means a single compromised component can propagate risk across thousands of downstream consumers.
Regulatory requirements are increasing to handle this risk. Executive Order 14028 and frameworks such as NIST’s Secure Software Development Framework (SSDF) require organizations to demonstrate stronger supply chain security controls, particularly around build integrity and provenance.
Addressing this risk requires a standardized approach to securing how software is built and verified across the supply chain. This is the problem SLSA is designed to solve.
Who is SLSA for?
SLSA is useful whenever one team produces software that another team or customer consumes. It applies to both internal platforms and external software distribution.
Software producers: Open source maintainers, commercial software vendors, and internal development teams that build artifacts such as containers, packages, and binaries for others to use.
Software consumers: Organizations that evaluate and deploy third-party dependencies, internal libraries, and base images, including teams with procurement or compliance requirements.
Infrastructure providers: Build platforms, package managers, and CI/CD service providers responsible for the environments where software artifacts are created, signed, and distributed.
Watch 5-min Wiz Code demo
Watch how Wiz scans code, dependencies, and CI/CD pipelines to catch vulnerabilities, exposed secrets, and misconfigurations before they reach production.
SLSA security levels
SLSA defines three security levels for the build track, each with stricter requirements. Version 1.0, released by OpenSSF in April 2023, focuses on build integrity rather than the entire software lifecycle.
The levels are cumulative. Meeting Level 2 includes Level 1 requirements, and Level 3 builds on both. This structure allows organizations to adopt SLSA incrementally without requiring a complete overhaul of existing pipelines.
SLSA Level 1
Level 1 focuses on provenance, which is a record of how an artifact was built. It captures details such as the source repository, commit hash, dependencies, and a cryptographic digest of the output.
This metadata establishes traceability and helps prevent errors such as releasing the wrong version.
However, Level 1 provenance is unsigned and can be modified. If an attacker alters the metadata, downstream consumers have no way to detect the change. Level 1 assumes the build platform is trustworthy, but does not verify it.
SLSA Level 2
Level 2 introduces signed provenance and dedicated build infrastructure.
Signed provenance allows the build platform to cryptographically attest to the origin of an artifact. If the metadata is modified after signing, the signature becomes invalid, and the tampering is detectable. Dedicated infrastructure ensures builds run on controlled systems rather than developer workstations, reducing exposure to compromise.
Level 2 improves integrity after the build, but it does not address risks during the build process. Compromised credentials or shared environments can still introduce malicious changes.
SLSA Level 3
Level 3 introduces build isolation and secret protection, addressing the gaps in Level 2.
Build isolation ensures each build runs in an ephemeral environment that is independent of other processes. This prevents one compromised build from affecting another. Secret protection separates signing credentials from user-defined build steps, so build scripts cannot access or misuse signing keys.
These controls enable three outcomes:
Reproducible builds: Identical inputs produce identical outputs, allowing independent verification.
Tamper-resistant builds: Isolation and secret protection reduce the risk of unauthorized changes.
Downstream trust: Consumers can verify provenance and make informed decisions about software integrity.
Get the Application Security Best Practices [Cheat Sheet]
This 6-page guide goes beyond basics — it’s a deep dive into advanced, practical AppSec strategies for developers, security engineers, and DevOps teams.
Limitations of the SLSA framework
SLSA is not a complete solution. Understanding its limitations helps you apply it effectively and identify where you need additional controls.
Complexity and cost: Higher SLSA levels require changes to CI/CD pipelines, isolated build environments, and stronger key management practices, which can be challenging for less mature teams.
Limited scope: SLSA focuses on build integrity, not the full software lifecycle. It doesn’t cover runtime security, vulnerability management, or incident response.
Third-party dependencies: Provenance shows how your artifact was built, but doesn’t guarantee that upstream components were built securely.
Customization requirements: As a general framework, SLSA often requires additional controls to meet the needs of regulated industries such as finance or healthcare.
Evolving ecosystem: Support for provenance, signing, and verification varies across platforms, and many implementations still depend on manual processes or custom integrations.
SLSA framework use cases in real-world scenarios
SLSA can be applied across different environments to strengthen software supply chain security, with each use case aligning to specific SLSA levels and controls.
| Use case | SLSA level and controls | Security outcomes |
|---|---|---|
| Securing CI/CD pipelines | Level 2: Signed provenance, dedicated and controlled build infrastructure | Ensures build integrity, prevents tampering, and creates an auditable record to support compliance |
| Ensuring trust in open source software | Level 3: Isolated build environments, protected signing processes | Enables verification of artifact provenance and ensures builds are reproducible and tamper-resistant |
| Securing cloud-native applications | Level 3: Secure build tools (e.g., Tekton), artifact signing (e.g., Sigstore), policy enforcement (e.g., Kubernetes admission controls) | Ensures only trusted artifacts are deployed, improves traceability, and accelerates incident response |
SLSA implementation best practices
Implementing SLSA does not require a full redesign. Most teams start by tightening key build controls, then expand coverage as their processes mature.
Assess and choose the right SLSA level
Start by assessing your current build systems and deciding what level you can support with your current tooling and ownership model.
Level 1: Start producing provenance so releases are traceable.
Level 2: Add signed provenance and move builds onto protected infrastructure.
Level 3: Add strong build isolation and restrict access to signing secrets.
Secure your build environment
Run builds on dedicated, controlled infrastructure rather than developer workstations. Keep build systems patched, isolate build runs, and enforce access controls to reduce the risk of interference or compromise.
Standardize and reproduce build processes
Ensure builds are reproducible by using consistent inputs and configurations. Identical inputs should produce identical outputs. Pair this with a Software Bill of Materials (SBOM) to track dependencies and improve traceability.
Harden and manage build credentials
Store credentials in a secure vault, rotate them regularly, and enforce MFA and RBAC for systems that publish or sign artifacts. Avoid hardcoding secrets—Wiz's 2025 State of Code Security Report found that 61% of organizations have secrets exposed in public repositories. Use a Key Management System (KMS) to manage and protect signing keys.
Monitor and audit build activity continuously
Log build actions, provenance generation, and artifact publishing events. Use centralized logging and anomaly detection to identify unusual activity and support investigation of build-related incidents.
How Wiz helps secure software supply chains
Wiz extends supply chain security beyond the build phase by connecting code, pipelines, and runtime context to identify which risks are actually exploitable, not just theoretical.
Wiz Code enables shift-left security by scanning repositories and CI/CD pipelines for vulnerabilities, misconfigurations, and exposed secrets, while Software Composition Analysis (SCA) identifies risks in open-source dependencies across containers, IaC, and cloud workloads.
Wiz continues this visibility through deployment, enforcing policy-as-code controls, verifying trusted artifacts, and monitoring pipeline configurations. At runtime, the Wiz Security Graph correlates vulnerabilities, identity permissions, and data exposure to prioritize the risks that matter most and accelerate incident response. Wiz also extends this context to AI workloads by mapping model pipelines, training data, and AI-specific dependencies.
Ready to evaluate your supply chain risk? Request a demo to see how Wiz secures modern cloud environments.
Catch code risks before you deploy
Learn how Wiz Code scans IaC, containers, and pipelines to stop misconfigurations and vulnerabilities before they hit your cloud.
