The best software development teams are constantly looking for ways to secure their software supply chains, ensuring the authenticity and quality of open source software components they consume. Just as food products should have a set of safety guidelines to ensure the ingredient list is credible and untampered, software products should have a similar set of safety guidelines to guard against unexpected alterations or substitutions. In this post, we'll explore how SLSA can help secure your software supply chain and provide a safer software development environment.
Editor's note: Much of the overview below has been generously summarized from SLSA's website. We'll keep it mostly high-level, so head over to SLSA.dev to learn even more.
SLSA is a framework that helps build or improve software supply-chain security by providing guidelines for securing the software development life cycle (SDLC). In many ways, SLSA is similar to food safety handling mentioned previously. Digging a bit deeper, SLSA (Supply Chain Levels for Software Artifacts) is a comprehensive set of guidelines developed and maintained by the open source community. The project itself officially released version 1.0 in April 2023 and is housed under The OpenSSF, and, in many ways, pairs nicely with the recently released Open Source Consumption Manifesto, also published by Open SSF. In the SLSA team's own words, "The specification set by SLSA is useful for both software producers and consumers: producers can follow SLSA's guidelines to make their software supply chain more secure, and consumers can use SLSA to make decisions about whether to trust a software package."
On the production side, SLSA's guidelines help strengthen critical parts of their software supply chain. In the context of software development, SLSA provides key best practices to ensure software products meet the increasing expected standards related to software security. However, on the consumer side, for example, open source consumption, SLSA helps software manufacturers make informed decisions about trusting a software package.
SLSA notes the significance of events like the SolarWinds and Codecov breaches in highlighting the risk associated with vulnerable software supply chains. While transformational in shaping perspective, these are just two incidents in a long line of a multi-trillion-dollar industry built around attacking software supply chains. A decade ago, a vulnerability or code quality would be the most likely culprit, but the landscape is changing. Today, these weaknesses not only stem from the quality of code being written, which is critically important, every link in the software supply chain is a potential point of attack as well. Given this, a language-agnostic, and thus universal framework like SLSA, is crucial to securing and fortifying software supply chains.
SLSA operates on tracks and levels. A track focuses on a specific aspect of the software supply chain (e.g., the Build Track). Higher levels in a track offer better protection against supply chain threats but may require more resources to implement. The combination of tracks and levels provides a clear way to communicate whether the software meets certain security requirements.
To better understand this, imagine you want to improve open source consumption. A key place to start is by ensuring the open source software you are using can be verified during your build. You're just getting started, so you've chosen the Build track, Level 1 (Build L1). For this level and track, SLSA provides a set of requirements.
Based on the above, your artifact verification process is most concerned with ensuring the package provides information identifying where it says it came from, and how it was built (i.e., provenance). Next, you can focus on how to actually verify the provenance information that has been provided. At Build L1 you'll only be concerned with the existence of provenance data. However, as you progress, other levels will have more detailed requirements and steps for verifying artifacts.
While SLSA is a crucial part of supply chain security, it doesn't cover every aspect. It doesn't address code quality issues or set requirements for secure coding best practices. It also won't address a package developed by organizations with the intent to be malicious. Finally, SLSA treats direct and transitive dependencies the same.