TL;DR overview
- SLSA (Supply Chain Levels for Software Artifacts, pronounced 'salsa') is an industry-standard framework of checklists that helps software producers secure their build pipelines and gives consumers a common language to evaluate the security of packages they depend on.
- The framework is organized into tracks and levels; the build track has four levels (L0–L3) representing increasing grades of security, from no provenance at L0 to a hardened, isolated build platform with authenticated, signed provenance at L3.
- Higher build levels provide concrete supply chain security benefits: L1 establishes basic provenance, L2 adds hosted builds and digital signatures to prevent tampering, and L3 enforces platform isolation and confidentiality controls.
- Organizations can use SLSA alongside software composition analysis and static code analysis to build a comprehensive software supply chain security posture.
What is SLSA?
SLSA (Supply Chain Levels for Software Artifacts; pronounced “salsa”) is a set of standards created and agreed upon by industry leaders and organizations. These standards aim to simplify software supply chain security management by creating checklists for software producers to ensure security for their package(s), while providing a common language for software consumers that help signal that a package is secure from unwanted tampering.
How SLSA works
Within the SLSA framework are different tracks. Tracks are composed of levels, incremental steps that build on one another that show increasing grades of security within a track. A higher level within a track signals a more secure software package on that defined basis.
What are the SLSA tracks and levels?
Build track
The purpose of the SLSA build track is to show that the package was built as expected and as the build levels increase, so does the security of the package’s provenance. Package provenance tells software consumers how the package was built, who built it, and what its composed of. By having this knowledge, consumers can better understand and decide on which packages are fit for consumption based on their associated build level.
Build level 0
Build level 0, or build L0, represents no presence of SLSA; no requirements are met.
Build level 1
Build level 1, or build L1, shows that provenance exists which shows how the package was built, including the build platform and build process. This level helps organizations, software producers, and software consumers to better understand the source of the software they’re downloading, making it easier to debug and analyze and in turn, assist in creating an inventory of the software in use in their own applications. However, this level only requires that the provenance exists—the provenance may be incomplete or unsigned, a requirement that is met in later levels.
Build level 2
Build level 2, or build L2, shows that builds run on a hosted platform (such as GitHub Actions), not a personal workstation, and that said hosted platform generates and signs the provenance (e.g. an authenticity key). Alongside the benefits of Build L1, when Build L2 requirements are met, consumers can expect a more secure package; limiting builds to specific build platforms lowers risk by reducing areas of attack and digital signatures prevent unwanted bad agents from accessing the package’s code. This build level goes a step further in ensuring that the code is secured and maintained in an appropriate build environment with authentication checks.
Build level 3
Build level 3, or build L3, is the final level of the build track and involves running bills on a hardened build platform. To be at build L3, all of the requirements of build L2 must be met along with using a build platform that enforces strict security standards that prevents runs from influencing one another (even in the same project) and prevents confidential information used to authenticate the build from being accessible. These benefits further prevent unwanted access to a package’s code and reduce the impact of compromised uploads from exploiting the package. In summary, build L2 ensures that the build platform is hosted and authentic whereas build L3 ensures that it is hosted, authentic, isolated, and secured.
Sources: https://slsa.dev/spec/v1.0/levels, https://slsa.dev/spec/v1.0/requirements
Conclusion: SLSA benefits
Anyone creating software applications can benefit from using SLSA. Internal users can use SLSA to ensure builds are secure through the build process. Those consuming open source software can use package ecosystems to verify SLSA provenance to help verify that the open source your organization is using meets your defined standards. Open source producers can use SLSA to help measure their security against a recognized framework, which in turn helps to promote usage of their package.
The SLSA framework is not static in nature, it was built to evolve with growing software supply chain security requirements. Visit the future directions section of the SLSA website for more information on the possible future of SLSA, including new tracks.