Definition
The SLSA Framework (Supply-chain Levels for Software Artifacts) is a security standard from the OpenSSF that helps secure the software build process. It aims to reduce tampering risks, add traceability, and ensure artifact integrity by guiding teams to build software in a verifiable, trustworthy way.
Overview of the SLSA Framework
The latest version of SLSA, v1.1, consists of progressive security levels (SLSA 0–3), each representing a stronger set of controls over the software build process. Core principles include:
- Provenance – Verifiable records of how software is built
- Tamper resistance – Protection against unauthorized modifications
- Isolation and reproducibility – Builds occur in secure, controlled environments
The framework is tool-agnostic and can be adopted incrementally based on a team’s security maturity.
The Role of SLSA in Enhancing Software Integrity
SLSA helps organizations build trust in their software by enforcing best practices that ensure software is authentic and reliable. It makes it easier for teams and end users to verify that software has not been altered and is safe to use—playing a key role in modern software supply chain security.
Vulnerabilities can be introduced anywhere along the software supply chain (Source: SLSA.dev)
SLSA and GRC: A Fundamental Framework for Compliance-Ready Software
As GRC (Governance, Risk, and Compliance) becomes increasingly important for businesses, SLSA provides a proven framework to demonstrate software supply chain security. Recognized by industry, SLSA provides a common language that streamlines how businesses work with regulators and auditors, helping build trust and ultimately establish compliance.
The Growing Need for Supply Chain Security
Modern software depends on open source and third-party components, making the supply chain a prime target for attackers. SLSA addresses these risks by providing a framework of strict build controls, automated verification, and traceable artifact records—helping teams prevent tampering, support forensic investigations, and align with other common standards such as SSDF and EO 14028.
How SLSA Addresses Vulnerabilities and Risks
SLSA tackles overlooked risks in the software supply chain—like tampered builds and insecure dependencies—by securing the build process itself. It enforces provenance, isolated builds, and verifiable records to prevent unauthorized changes and detect compromise early. With its tiered levels, organizations can gradually close security gaps and gain more control over their software lifecycle.
Benefits of Adopting the SLSA Framework for Organizations
Adopting SLSA boosts software integrity, reduces incident response, improves trust with users and stakeholders, and supports more streamlined auditing to prove compliance with standards like SSDF and EO 14028.
SLSA Security Levels Explained
The SLSA Framework defines four progressive levels of assurance, each designed to strengthen software supply chain integrity. These levels can be adopted incrementally, allowing organizations to mature their security posture over time based on risk, resources, and business needs. Here is what’s in the SLSA security levels in SLSA v1.1 (latest framework as of April 2025):
Level 0 (L0): Represents no SLSA implemented, and a lack of provenance. Should be used only when development and test builds of software are built and run on the same local machine.
Level 1 (L1): Establish the foundation for provenance
Criteria: The build platform must automatically generate provenance describing how the artifact was built. Provenance must also be available to be distributed to consumers.
Meeting SLSA L1 helps organizations establish a basic provenance foundation that they can build on.
Level 2 (L2): Host provenance on a hosted build platform
Criteria: The build platform must be able to automatically generate and sign the provenance itself. Consumers must be able to validate the authenticity of the provenance.
Meeting SLSA L2 helps organizations prevent tampering of builds through digital signatures. It also reduces their attack surface, and deterring adversaries from evading security controls.
Level 3 (L3): Further hardening of builds
Criteria: The build platform must have controls that establish more confidence that the package was built from the official source and build process. There must be controls that prevent runs from influencing one another (even within the same project), and prevent secret material used to sign the provenance from being accessible to the user-defined build steps.
Meeting SLSA L3 takes another step above L2 to prevent tampering during the build by compromised credentials or insider threats. L3 makes forging provenance extremely difficult.
In practice, these levels help teams weigh security needs against implementation effort. By meeting the criteria for each stage, organizations can build trust and resilience into their software supply chains—one level at a time.
Best Practices for Implementing SLSA
Steps for Integrating SLSA into Your Software Development Lifecycle
- Baseline with SBOMs: Start by generating Software Bill of Materials (SBOMs) to identify components and dependencies.
- Automate Builds: Use hosted CI/CD systems to reduce the risk of tampering and ensure repeatability.
- Adopt Version Control Hygiene: Enforce code reviews, sign commits, and restrict access to repositories.
- Generate and Verify Provenance: Use tools that support cryptographic signing and validation of artifacts.
- Set Realistic SLSA Goals: Start with small wins, and work your way up. Establish Level 1 first, then move your way up to Level 3 as your pipeline matures.
Common Pitfalls to Avoid
SLSA implementation can fall short when teams rely on manual build processes, skip provenance checks, or inconsistently apply version control and access policies. Without proper training on secure development practices, teams may struggle to maintain compliance or fully realize the framework’s benefits.
Tools to Support SLSA Implementation
The foundation to supporting SLSA implementation starts with an automated evidence collection tool which captures provenance. You can leverage open-source tools like Sigstore (including Cosign and Rekor) to support signing and verifying software provenance. The SLSA.dev site offers up-to-date specifications and documentation, and in-toto provides a framework for securing the entire software supply chain.
Other vendors also provide integrated automated evidence collection solutions, from compliance automation providers, DevOps Platforms, to ASPM vendors. We recommend finding a solution that works best to help you streamline your SDLC with the full application context to help you scale your SLSA compliance.
How JFrog Supports SLSA
JFrog supports SLSA adoption by securing every phase of the software build and delivery process. JFrog’s Evidence Collection automates the collection of signed evidence throughout the SDLC, helping you align your builds to SLSA levels more seamlessly. JFrog Artifactory provides secure artifact storage with built-in traceability, while JFrog Xray enables vulnerability scanning and policy enforcement. For more information, please visit our website, take a virtual tour, or set up a one-on-one demo at your convenience.
