SLSA Explained – Framework, Levels and Implementation Best Practices

Updated: 19/04/2026

What Is SLSA?

SLSA, pronounced “salsa,” stands for Supply-chain Levels for Software Artifacts. It is a set of incrementally adoptable guidelines for software supply chain security that helps organizations strengthen the integrity of software artifacts and reduce the risk of tampering during software development and delivery. SLSA is maintained as a project of the Open Source Security Foundation (OpenSSF) and developed through industry consensus, which is one reason it has become an important common language for software supply chain assurance.

At a practical level, SLSA helps software producers and software consumers evaluate how software is built, where it comes from, and how much trust they can place in the resulting artifacts. Rather than treating software supply chain security as an abstract goal, it turns it into a more structured and measurable path for improvement.

SLSA Compliance and Future-proofing snapshot

Organizations that improve provenance, build integrity, dependency governance, and artifact trust today are typically better positioned for customer reviews, audits, procurement scrutiny, and future regulatory change. That is one reason SLSA is becoming more important even when it is not explicitly mandated.

Why SLSA Matters

Modern software supply chains are exposed to a growing range of risks. Vulnerable dependencies, compromised build environments, malicious packages, tampered artifacts, and weak provenance can all undermine trust in the software organizations build or consume.

SLSA matters because it helps organizations move from general awareness of software supply chain risk to a more practical and measurable security model. It gives teams a shared way to reason about trust, integrity, and build assurance, while also providing a roadmap for improving security over time.

The SLSA framework can help secure against these risks by providing:

Compliance and Assurance – An organization that adopts SLSA can demonstrate to their customers and stakeholders that it is following rigorous security practices. This is increasingly important as expectations around software security continue to rise.

Prevention of Supply Chain Attacks – By adhering to SLSA levels, organizations can mitigate the risk of various types of supply chain attacks. This includes identifying and mitigating risks associated with third-party dependencies and the build environment, preventing tampering during the build and distribution processes, and ensuring the integrity of software components.

Standardization of Best Practices – SLSA provides a set of industry-standard best practices that organizations can adopt to secure their software supply chains. This standardization helps in creating a common understanding and approach towards supply chain security. As more organizations adopt SLSA practices, the overall software ecosystem becomes more secure, making it more difficult for attackers to exploit supply chain vulnerabilities.

Incremental Security Improvements – SLSA defines a roadmap of four levels of security maturity, from Level 0 (basic security requirements) to Level 3 (high assurance). This allows organizations to progressively improve their security posture over time, aligning with their specific risk profiles and resource availability.

Incident Response – In the event of a supply chain attack, SLSA’s emphasis on provenance and build integrity can aid in faster incident response and impact assessment.

Provenance and Transparency – One of the core tenets of SLSA is to ensure the provenance of software artifacts. This means having verifiable metadata about where software components come from, how they were built, and how they were distributed. This transparency builds trust and accountability in the software supply chain.

For software producers, that means stronger build trust and clearer evidence of how software was created. For software consumers, it means better signals for deciding whether a package, image, or artifact should be trusted.

How the SLSA Framework Works

SLSA works by defining progressively stronger expectations for software supply chain security. Its focus is on improving confidence in the integrity of the software production process.

Provenance

One of the most important concepts in SLSA is provenance. Provenance is the metadata that explains how an artifact was produced, including what source it came from, what build process created it, and what environment performed the build.

Strong provenance helps teams verify integrity, investigate issues, and make better trust decisions about the software they use or distribute.

Build Integrity

SLSA also emphasizes protecting the build process itself. If the build environment can be tampered with, then even trusted source code can produce untrusted artifacts.

That is why SLSA places importance on stronger build controls, more trustworthy build systems, and better verification of how software artifacts are generated.

Incremental Adoption

SLSA is designed to be adopted progressively. Organizations do not need to reach the highest level immediately. Instead, they can use the framework as a roadmap to improve software supply chain security step by step.

That makes SLSA practical for teams at different stages of security maturity. OpenSSF explicitly positions SLSA as incrementally adoptable guidance rather than an all-at-once maturity hurdle.

SLSA Levels Explained

SLSA describes progressively stronger levels of assurance. The exact requirements can evolve over time, but the general principle remains consistent: each level adds stronger controls and greater confidence in the integrity of software artifacts.

SLSA defines four progressive levels, each with its own set of requirements.

Each level builds upon the previous one, adding more security and assurance.

Level 0: No protection (prior to adoption of SLSA)

Level 1: Adding provenance

Provenance is added to provide information about the build process: how the artifact was built, the build platform and process, etc. This enables the software producer and its consumers to patch, debug and rebuild software, and helps prevent mistakes in the release process.

Level 2: Using a hosted build platform

The hosted platform runs on dedicated infrastructure and signs the provenance with a digital signature for authenticity. This helps prevent tampering, deters insider threats, and reduces the attack surface.

Level 3: Hardened builds

Using a hardened build platform with strong tamper protection. This requires changes to the build platform but prevents tampering, reduces the impact of compromised packages, and provides confidence in packages.

With SLSA, AppSec teams and developers incorporate security practices into the enterprise’s build processes, so they have more confidence in the supply chain software artifacts they consume. From a business perspective, companies that prioritize and implement SLSA’s supply chain security practices can differentiate themselves in the market, providing an edge over competitors.

How to Start Implementing SLSA

For most teams, implementing SLSA begins with visibility and consistency.

Start by documenting how software is built today, including the source repositories, build systems, artifact repositories, and dependency sources involved in the delivery process. From there, focus on improving provenance, reducing manual or untrusted build steps, and strengthening control over dependencies and build environments.

Implementation should be practical and phased. Teams do not need to redesign the entire software pipeline at once. Instead, they should identify the highest-risk gaps first, then improve controls incrementally.

A good starting point usually includes:

• documenting build workflows
• strengthening version control and branch protections
• improving dependency governance
• introducing artifact signing and provenance where possible
• tightening CI/CD security controls
• reducing the use of unverified or risky third-party components

Best Practices for Using SLSA in Software Supply Chain Security

Implementing the SLSA framework effectively requires adherence to best practices that align with the framework’s requirements and goals.

Since SLSA is evolving and attempts to remain a framework and not a guide, this list is constantly evolving and should be accompanied with research of additional practices required for your security needs.

Here are some best practices for using SLSA in software supply chain security:

• Provide regular training for developers on secure coding practices, SLSA requirements, and the importance of software supply chain security.
• Use a robust version control system like Git. Ensure all changes are tracked, and the history is immutable.
• Require developers to sign their commits to verify the authenticity of code changes.
• Implement branch protection rules to prevent unauthorized changes, such as requiring pull requests for all changes and enforcing code reviews.
• Use isolated and ephemeral build environments to ensure that each build is independent and cannot be influenced by previous builds or external factors.
• Prevent secret credentials and other sensitive information from being included in files or repositories where they might be exposed.
• Aim for reproducible builds, where the same source code always produces the same binary. This helps detect tampering and inconsistencies.
• Use vetted and controlled dependencies, and ensure they come from trusted sources. Scan with SCA tools and regularly update dependencies to patch vulnerabilities.
• Automatically generate detailed provenance metadata for each build, including information about the source code, build environment, and dependencies. You can use an automated SBOM solution for this.
• Sign all provenance metadata and build artifacts using cryptographic keys. Ensure these keys are securely managed and rotated regularly.
• Store provenance metadata in a secure, immutable, and accessible manner, such as in a blockchain or trusted database.
• Conduct regular security scans and audits of your build and supply chain processes to detect vulnerabilities and malicious packages and ensure compliance with SLSA requirements.
• Have a clear incident response plan in place for handling supply chain security incidents, including steps for containment, investigation, and remediation.
• Integrate SLSA best practices into your CI/CD pipelines to automate compliance and reduce manual errors.
• Use security tools that support SLSA practices, such as those for static analysis, dependency scanning, and secret management.

SLSA, Compliance, and Future-Proofing

SLSA is not a compliance regime by itself, but it is increasingly useful for organizations that need to show stronger software supply chain discipline. OpenSSF explicitly notes that SLSA can help organizations measure efforts toward compliance with the NIST Secure Software Development Framework (SSDF). That matters because SSDF-aligned practices are part of the broader U.S. federal software supply chain push that followed Executive Order 14028.

It is especially relevant for industries and organizations that face higher expectations around software integrity, traceability, and secure development practices, including:

• government and defense contractors
• regulated healthcare and medical device manufacturers
• financial services
• critical infrastructure and industrial technology
• enterprise software vendors selling into regulated or security-sensitive markets

Several current and emerging requirements make this more urgent:

U.S. federal software supply chain expectations

Executive Order 14028 pushed U.S. agencies and standards bodies to strengthen software supply chain security guidance, including the use of SSDF-aligned practices. SLSA is useful here because it provides practical ways to strengthen build trust, provenance, and artifact integrity.

EU Cyber Resilience Act

The EU Cyber Resilience Act raises expectations for products with digital elements, including vulnerability handling and reporting.

The European Commission states that manufacturers must begin reporting actively exploited vulnerabilities and severe incidents starting 11 September 2026, which makes stronger supply chain discipline and traceability increasingly important.

NIS2

NIS2 has already raised the baseline for cybersecurity risk management and supply chain considerations across essential and important entities in the EU.

The directive required Member States to transpose it by 17 October 2024, making software supply chain security and vendor governance more operationally relevant for affected organizations.

Are you NIS2, DORA and CRA Proof?

Self-assess your AppSec maturity in minutes with 12 questions. Identify gaps, prioritize improvements, and get a practical roadmap – including specialized assessments, such as for EU regulations like NIS2, DORA, and CRA.

Start the Assessment

FDA cyber-device requirements

For applicable cyber devices, FDA section 524B requirements have applied to relevant premarket submissions since 29 March 2023, including expectations around postmarket vulnerability management and a software bill of materials (SBOM). For medical device manufacturers, this makes software component visibility and supply chain trust highly relevant.

Why this matters for future-proofing

Even where SLSA is not explicitly mandated, the direction of travel is clear: buyers, regulators, and enterprise customers increasingly expect stronger evidence that software is built in a trustworthy way. Adopting SLSA-aligned practices now can help organizations:

• improve readiness for customer security reviews
• support vendor and procurement questionnaires
• strengthen regulated-product submissions
• reduce future compliance friction
• create stronger evidence of secure software development practices

In that sense, SLSA is not only a security framework. It is also a practical way to future-proof software delivery processes against rising trust and assurance expectations.

Who Owns SLSA in the SDLC?

SLSA is a shared responsibility that involves executive leadership, security teams, development teams, QA, operations, and compliance professionals.

By working together and adhering to the SLSA framework, organizations can significantly enhance the security and integrity of their software supply chains.

Executive Leadership – CISO, CTO, CIO

• Set strategic goals for software supply chain security.
• Allocate resources and budgets for implementing SLSA.
• Ensure organization-wide adherence to security policies and frameworks.

Security Team – Security Architects, Security Engineers, Compliance Officers

• Develop and enforce security policies and best practices related to SLSA.
• Conduct threat modeling and risk assessments.
• Implement security controls and monitoring solutions.
• Ensure compliance with relevant regulations and standards (e.g., GDPR, HIPAA, NIST).

Engineering Team – Developers, DevOps, QA

Monitor and respond to security incidents related to the software supply chain.n that builds, distributes, or depends on modern software can benefit from the framework.

Integrate SLSA practices into the CI/CD pipeline.

Ensure secure coding practices and proper dependency management.

Maintain the integrity of the build environment and tooling.

Perform security testing, including static and dynamic analysis.

Manage the infrastructure and environments where software is built, tested, and deployed.

Ensure secure configurations and patch management.

How Checkmarx Supports SLSA and Software Supply Chain Security

SLSA is most useful when it is supported by practical controls across the software supply chain. Checkmarx helps organizations strengthen software supply chain security through capabilities that support dependency governance, malicious package detection, secrets detection, policy enforcement, and risk prioritization across modern development workflows. These capabilities are designed to improve visibility into open-source usage, repository hygiene, package trust, and build-related risk while fitting naturally into IDEs, CI/CD pipelines, and governance workflows.

That matters because SLSA depends on operational discipline, not just conceptual alignment. Teams need practical ways to assess dependencies, block malicious packages, enforce policies, and improve trust across software delivery workflows. Checkmarx supports that by connecting supply chain signals into a broader application security context and helping teams act on them earlier and with more consistency.