Google has recently introduced the Supply chain Levels for Software Artifacts or SLSA (pronounced “salsa”) framework. This framework is in its early stages and has been released as part of OpenSSF Foundation. SLSA is intended to replicate what Google has been doing internally to address the software composition problem and reduce the software development supply chain attack vectors. Let’s dive in:
Why Do We Need ‘Yet Another Standard’
As discussed in past posts, software is generally a combination of 3rd party code from open source libraries and new code from the development team. The use of open source libraries have many benefits including peer reviewed code, standardization and repeatability, however that first benefit, “peer reviewed”, is where hackers have been taking advantage of our implicit trust of open source. Software development teams want a better solution to managing supply chain attack vectors but until now, there has not been a framework or standard that comprehensively addresses the risk.
What is SLSA?
SLSA is a framework that attempts to standardize the definition of “secure” software supply chains through increasing awareness and providing guiding principles and eventually supported by auditable technical controls. Currently, the framework has 4 assurance levels providing incremental integrity guarantees, very similar to OWASP’s ASVS. While the framework is quite new and more of a guideline then a standard at this point, the eventual goal is focused on being able to measure and accredit organization’s SDLC capabilities against the standard.
The Core Principles
Currently SLSA has two core principles: Non-Unilateral and Auditable. The Non-unilateral principle focuses on the prevention of a single individual making changes to a software artifact without review and approval. This is to prevent and deter risky behaviour within software development and reduce exposure to external threats. The second principle is Auditable and is focused on traceability of source and related dependencies and support investigative capabilities.
SLSA Levels
The current version of SLSA has 4 levels of assurance. SLSA Level 1 acts as a stepping stone providing moderate confidence of who authorized the artifact or what produced the artifact and provides controls to protect against tampering after the build. SLSA Level 2 provides auditability of the provenance of the artifact. SLSA 3 adds controls related to preventing a single individual from making changes within the supply chain without review and approval and increased integrity controls. And lastly, SLSA Level 4 was recently added to the developing framework and is focused on strong controls to prevent modification and dependency completeness.
Is SLSA right for you?
The software supply chain is a real threat to any organization that is developing software. SLSA is in its infancy and should be considered a framework of guiding principles rather than a standard at this juncture. That said, given the threat horizon ahead, we see this project gaining steam, maturing and eventually becoming table stakes for dev teams around the globe.
For now we would recommend increasing awareness of the software supply chain problem and exploring how your development team can start integrating SLSA principles and controls within your SDLC.
Want to learn more about SLSA? Check out their Github: https://github.com/slsa-framework/slsa
COMMENTS