Building trust in our software supply chains with SLSA
If you’re worried about software supply chain attacks and unsure of how to tackle the problem or align your team on a roadmap, this series on SLSA is for you.
What is SLSA?
SLSA or “Supply-chain Levels for Software Artifacts” is a framework for ensuring the integrity of software artifacts to prevent attacks. It can be thought of as a supply chain security capability model. SLSA launched about a year ago under the OpenSSF, and has grown to over 30 contributors from organizations including Citi, Intel, VMWare, Datadog, and us here at Chainguard. Inspired by Google’s decade old process, which is mandatory for all production workloads, SLSA helps answer questions like “how do I trust the code I’m using hasn’t been tampered with?” and “how do I trust the build system or source code system used in producing this package?”
SLSA helps organizations and open source projects derisk the software development lifecycle by providing a set of guidelines across the develop -> build -> release cycle. Establishing a common language for risks and mitigations allows software professionals to communicate and act on those risks across organizational boundaries. By knowing the SLSA level, consumers can reason about a software package or build platform’s security posture and make decisions about what to trust. For example, an organization may decide that its developers can’t deploy code that doesn’t meet SLSA 2 or that their vendors need to meet higher SLSA levels before signing a contract.
What makes SLSA unique compared to other guides is that instead of only being a list of best practices to follow, it’s designed around the automatic creation of verifiable metadata. This metadata can then be used in policy decisions such as the examples given above. It’s not only about the process of securing the software supply chain, it’s about actually doing it, and having the data to prove it. The latest provenance specification is available here.
SLSA details
SLSA currently consists of four levels. Each level adds additional security requirements. From source to system, the levels blend together industry-recognized best practices to create four compliance levels of increasing assurance. The levels look at the builds, sources and dependencies in open source or commercial software.
Below is a more detailed view of the current levels and criteria. Information on each requirement and terminology can be found on the SLSA web page.
How to get started
The great part is that SLSA is not an “all or nothing” framework, as any incremental progress towards a higher level will provide real security benefits. A good place to start is to check out the getting started guide on the website for steps and tools to reach SLSA 1. The bulk of this work will be producing provenance data that will allow tracing of the software back to the source and visibility into the supply chain. To see how a larger project achieved SLSA 1, check out the path the Kubernetes project followed here.
How Chainguard can help
At Chainguard, we’re making the SLSA framework part of everything we do. We’re providing services and building holistic solutions to help organizations achieve higher SLSA levels and progress in their software supply chain security journey, and following SLSA for our own internal processes. If you’re interested in getting on our early access list, or chatting about ways we can help you, please fill out the form here.
Conclusion
Stay tuned for more posts about SLSA including a deep dive into the threats that SLSA helps protect against, how organizations are using SLSA today, and how it compares to other frameworks.
If you’d like to learn more, or get involved with the SLSA community check out the SLSA Community Page for details.
Ready to Lock Down Your Supply Chain?
Talk to our customer obsessed, community-driven team.