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.
A standardized vocabulary: This is critical for teams, especially those just getting started, because it facilitates discussions around software supply chain security, ensuring a common understanding across the industry.
Criteria for component and artifact trustworthiness: The lack of awareness, especially for known vulnerabilities associated with open source consumption, is a growing concern. SLSA provides teams with a standard and specification to assess the reliability of the artifacts consumed in the supply chain, bolstering incoming security.
Security checklist: The software security industry has a host of great frameworks, but many of them, while detailed, don't always provide the level of actionable detail. SLSA provides an actionable checklist for improving the security of one's own software.
Compliance with executive order standards: In the wake of the Log4j exploit, the Executive Order on Improving the Nation's Cybersecurity called for a number of new standards related to software security. Following this, the National Cybersecurity Strategy in March 2023, in partnership with the Cybersecurity and Infrastructure Security Agency (CISA), are working to solidify these standards, many of which have already been added to the Secure Software Development Framework (SSDF). SLSA can assist teams in aligning with those standards and will be updated as those standards evolve.
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.
Software producers: This includes open source software projects, software manufacturers, or in-house development teams. SLSA safeguards against tampering in the supply chain, bolstering confidence that the software reaches consumers intact.
Software consumers: One example of this would be development teams using open source packages or government agencies relying on vendor software. SLSA provides a means to evaluate the security practices of the software they depend on.
Infrastructure providers: This includes package managers, build platforms, or CI/CD platforms. Adoption of SLSA ensures a secure software supply chain between producers and consumers.
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.
Software producer follows a consistent build process so that others can form expectations about what a "correct" build looks like.
Provenance exists describing how the artifact was built, including the build platform, build process, and top-level inputs.
Software producer distributes provenance to consumers, preferably using a convention determined by the package ecosystem.
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.