Supply-chain Levels for Software Artifacts, or SLSA ("salsa").
It’s a security framework, a checklist of standards and controls to prevent tampering, improve integrity, and secure packages and infrastructure. It’s how you get from "safe enough" to being as resilient as possible, at any link in the chain.
Any software can introduce vulnerabilities into a supply chain. As a system gets more complex, it’s critical to already have checks and best practices in place to guarantee artifact integrity, that the source code you’re relying on is the code you’re actually using. Without solid foundations and a plan for the system as it grows, it’s difficult to focus your efforts against tomorrow’s next hack, breach or compromise.
More about supply chain attacks
SLSA levels are like a common language to talk about how secure software, supply chains and their component parts really are. From source to platform, the levels blend together industry-recognized best practices to create four compliance levels of increasing assurance. These look at the builds, sources and dependencies in open source or commercial software. Starting with easy, basic steps at the lower levels to build up and protect against advanced threats later, bringing SLSA into your work means prioritized, practical measures to prevent unauthorized modifications to software, and a plan to harden that security over time.
Read the level specifications
SLSA is for everyone involved in producing, consuming, and providing infrastructure for software such as build platforms and package ecosystems. SLSA can help create more trust across the entire supply chain. It can be used by producers for protection against tampering and insider threats, by consumers to verify the software they rely on is secure, and by infrastructure providers as a guideline for hardening build platforms and processes.
An industry collaboration
SLSA is led by an initial cross-organization, vendor-neutral steering group committed to improving the security ecosystem for everyone.
Part of the Open Source Security Foundation
Our ethos
Today’s projects, products and services are increasingly complex and open to attack. As that trend continues, we need to scale up our effort to provide more secure, accessible ways to protect the development, distribution and consumption of the software we use, and all the impacted communities behind it.
“Regulated industries such as Financial Services are being more vocal on defining their responsibility on the software supply chain. Having control and traceability as a requirement is taking shape.”
Bruno Domingues
CTO, Financial Services Industry, Intel
“This is our chance to work with the industry, set a standard which we can all agree to, and work together to raise the collective bar.”
Trishank Karthik Kuppusamy
Staff Security Engineer at Datadog
“Software supply chain visibility will become a cross-industry need to establish best practices and trusted evidence in each link.”
Bruno Domingues
CTO, Financial Services Industry, Intel
“Having a common language and standard for objectively measuring our supply chain security is a must in order to even begin meeting EO 14028.”
Trishank Karthik Kuppusamy
Staff Security Engineer at Datadog
“The threat to the software supply chain is real and growing, 650% from the last year. However, changing development process without slowing down is a major barrier.”
Bruno Domingues
CTO, Financial Services Industry, Intel
“Regulated industries such as Financial Services are being more vocal on defining their responsibility on the software supply chain. Having control and traceability as a requirement is taking shape.”
Bruno Domingues
CTO, Financial Services Industry, Intel
“This is our chance to work with the industry, set a standard which we can all agree to, and work together to raise the collective bar.”
Trishank Karthik Kuppusamy
Staff Security Engineer at Datadog
Get started
Project status
SLSA v1.0 is now available, released in April 2023.
We expect the specification to remain stable, with future versions expanding its breadth and depth.
For more information about this release, see What's new in v1.0.
Google has been using an internal version of SLSA since 2013 and requires it for all of their production workloads.
