{"id":97693,"date":"2024-09-05T12:37:02","date_gmt":"2024-09-05T12:37:02","guid":{"rendered":"https:\/\/staging.checkmarx.com\/?post_type=glossary&p=97693"},"modified":"2026-04-23T16:58:35","modified_gmt":"2026-04-23T14:58:35","slug":"what-is-the-slsa-framework","status":"publish","type":"glossary","link":"https:\/\/checkmarx.com\/glossary\/what-is-the-slsa-framework\/","title":{"rendered":"SLSA Explained – Framework, Levels and Implementation Best Practices"},"content":{"rendered":"

Updated: 19\/04\/2026<\/em><\/p>\n\n\n

\n
\n\n

Summary<\/h2>\n\n\n\n

SLSA, short for Supply-chain Levels for Software Artifacts<\/strong>, is a software supply chain security framework designed to improve build integrity, provenance, and trust in software artifacts. Maintained as an OpenSSF project, it gives organizations a practical, incrementally adoptable way to strengthen software supply chain security and prepare for growing customer, regulatory, and compliance expectations.<\/p>\n\n<\/div>\n <\/section>\n\n\n

What Is SLSA?<\/h2>\n\n\n\n

SLSA, pronounced \u201csalsa,\u201d stands for Supply-chain Levels for Software Artifacts<\/strong>. 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<\/a>)<\/strong> and developed through industry consensus, which is one reason it has become an important common language for software supply chain assurance.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

SLSA Compliance and Future-proofing snapshot<\/h2>\n\n\n\n
\n\n\n\n\n\n\n\n
Requirement \/ Framework<\/th>\nIndustry<\/th>\nGeo<\/th>\nDue date<\/th>\nOne-sentence summary<\/th>\n<\/tr><\/thead>\n
EO 14028 \/ NIST SSDF guidance<\/strong><\/td>\nSoftware vendors selling to the U.S. federal ecosystem; broadly relevant to software producers<\/td>\nU.S.<\/td>\n\nMay 12, 2021<\/strong> for EO 14028; Feb 4, 2022<\/strong> for NIST Section 4e guidance<\/td>\nU.S. federal software supply chain expectations pushed vendors toward stronger secure development, testing, and software integrity practices, and SLSA can help measure progress toward SSDF-aligned maturity. (NIST<\/a>)<\/td>\n<\/tr>\n
FDA section 524B cyber-device requirements<\/strong><\/td>\nMedical device manufacturers and cyber-device submitters<\/td>\nU.S.<\/td>\nMarch 29, 2023<\/strong><\/td>\nApplicable FDA premarket submissions for cyber devices must include cybersecurity information, including an SBOM, making software component visibility and supply chain trust especially important. (U.S. Food and Drug Administration<\/a>)<\/td>\n<\/tr>\n
NIS2<\/strong><\/td>\nCritical infrastructure, digital services, cloud, data centers, managed services, health, energy, transport, manufacturing, and more<\/td>\nEU<\/td>\nOctober 17, 2024<\/strong><\/td>\nNIS2 raised the baseline for cybersecurity risk management across critical and important entities, increasing pressure for stronger supply chain oversight and software assurance. (Digital Strategy<\/a>)<\/td>\n<\/tr>\n
DORA<\/strong><\/td>\nFinancial services and financial-sector ICT dependencies<\/td>\nEU<\/td>\nJanuary 17, 2025<\/strong><\/td>\nDORA applies to the financial sector and strengthens operational resilience expectations, making software integrity, third-party risk, and supply chain discipline more operationally important. (EUR-Lex<\/a>)<\/td>\n<\/tr>\n
EU Cyber Resilience Act reporting requirements<\/strong><\/td>\nManufacturers of products with digital elements<\/td>\nEU<\/td>\nSeptember 11, 2026<\/strong><\/td>\nCRA reporting obligations begin in September 2026, increasing the importance of secure development, vulnerability handling, and stronger traceability across software-producing organizations. (Digital Strategy<\/a>)<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n

<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

<\/p>\n\n\n

\n
\n
\n\t\t\t\n\t\t\t

Benchmark Your AppSec Maturity<\/h2>\t\t\t

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.\r\n\r\n<\/p>\n\t\t\t

\n\t\t\t\t Take Free Assessment Now <\/a>\n \t\t\t\t\t\t\t<\/div>\n <\/div>\n <\/div>\n<\/section>\n\n\n


<\/p>\n\n\n\n

Why SLSA Matters<\/h2>\n\n\n\n

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

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.<\/p>\n\n\n\n

\n
The SLSA framework can help secure against these risks by providing:<\/h3>\n\n\n\n

Compliance and Assurance<\/strong> \u2013 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.<\/p>\n\n\n\n

Prevention of Supply Chain Attacks<\/strong> \u2013 By adhering to SLSA levels, organizations can mitigate the risk of various types of supply chain attacks<\/a>. 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.<\/p>\n\n\n\n

Standardization of Best Practices<\/strong> \u2013 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<\/a>. As more organizations adopt SLSA practices, the overall software ecosystem becomes more secure, making it more difficult for attackers to exploit supply chain vulnerabilities.<\/p>\n\n\n\n

Incremental Security Improvements<\/strong> \u2013 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.<\/p>\n\n\n\n

Incident Response<\/strong> \u2013 In the event of a supply chain attack, SLSA\u2019s emphasis on provenance and build integrity can aid in faster incident response and impact assessment.<\/p>\n\n\n\n

Provenance and Transparency<\/strong> \u2013 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.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

How the SLSA Framework Works<\/h2>\n\n\n\n

SLSA works by defining progressively stronger expectations for software supply chain security<\/a>. Its focus is on improving confidence in the integrity of the software production process.<\/p>\n\n\n\n

Provenance<\/h3>\n\n\n\n

One of the most important concepts in SLSA is provenance<\/strong>. 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.<\/p>\n\n\n\n

Strong provenance helps teams verify integrity, investigate issues, and make better trust decisions about the software they use or distribute.<\/p>\n\n\n\n

Build Integrity<\/h3>\n\n\n\n

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.<\/p>\n\n\n\n

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

Incremental Adoption<\/h3>\n\n\n\n

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.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

SLSA Levels Explained<\/h2>\n\n\n\n

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.<\/p>\n\n\n\n

SLSA defines four progressive levels, each with its own set of requirements. <\/h3>\n\n\n\n

Each level builds upon the previous one, adding more security and assurance.<\/p>\n\n\n\n

Level 0: No protection (prior to adoption of SLSA)<\/strong><\/p>\n\n\n\n

Level 1: Adding provenance<\/strong><\/p>\n\n\n\n

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.<\/p>\n\n\n\n

Level 2: Using a hosted build platform<\/strong><\/p>\n\n\n\n

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.<\/p>\n\n\n\n

Level 3: Hardened builds<\/strong><\/p>\n\n\n\n

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.<\/p>\n\n\n\n

With SLSA, AppSec teams and developers incorporate security practices into the enterprise\u2019s 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\u2019s supply chain security practices can differentiate themselves in the market, providing an edge over competitors.<\/p>\n\n\n\n

How to Start Implementing SLSA<\/h2>\n\n\n\n

For most teams, implementing SLSA begins with visibility and consistency.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

A good starting point usually includes:<\/p>\n\n\n\n