OpenSSF SLSA (formerly Google SLSA), announced in mid-2021, is a framework for ensuring the integrity of software artifacts throughout the software supply chain. SLSA is best described as a checklist of standards and controls to prevent tampering, improve software integrity, and secure packages and infrastructure.
SLSA provides an industry standard for communicating a recognizable and agreed-upon level of protection and compliance–this was partially in response to the executive order also prompting the creation of the NIST SSDF. The concept of levels within SLSA helps further this goal of clearly-communicated compliance, with SLSA 4 being the highest level of compliance and greatest security confidence.
SLSA is comprised of 5 categories of requirements:
- Source requirements
- Build requirements
- Provenance requirements
- Provenance content requirements
- Common requirements
These requirements have subitems that must all be fulfilled to hit SLSA 4. However, lower levels of SLSA may be hit with only partial satisfaction of the subitems. This brings us to one of SLSA’s key attributes: SLSA is prescriptive with its guidance, and any organization attempting to fulfill SLSA to improve its software supply chain security posture should do so with the eventual goal of fully complying with SLSA recommendations.
Applications of SLSA include reducing risk within an organization from insiders and compromised accounts, from consuming open source software, and from consuming vendor provided software and services.
One may use OpenSSF Scorecards to test SLSA compliance. Once installed, this verifier may be run with:
slsa-verifier -artifact-path <the-zip> -provenance attestation.intoto.jsonl -source github.com/ossf/scorecard -tag <the-tag>
SLSA is not applied to transitive dependencies with equal priority to dependencies. If SLSA 4 required dependencies to be SLSA 4, then reaching SLSA 4 would require starting at the very beginning of the supply chain and working forward. This would force developers to work on the least risky component first while also blocking downstream progress–this is backwards from what organizations want.
Learn how to protect & control your source code
Start building security workflows in minutes
Book a demo with our experts to learn how Cycode can help secure your software supply chainsBook a Demo