During this year’s KubeCon, attendees were treated to the first-ever SupplyChainSecurityCon North America, where VMware’s Joshua Lock joined forces with Google engineer Tom Hennen, to talk about Supply Chain Levels for Software Artifacts, or SLSA for short.
SupplyChainSecurityCon seems like an extremely specific conference, right? Well, according to CNCF and CD Foundation due to the uptick in supply chain attacks, this new event brings the community together to discuss supply chain threats, best practices, mitigation tactics including up and coming frameworks and specifications. At this inaugural conference, speakers unveiled teams and projects that function to create tighter security around a software supply chain, and the SLSA project is one which aims to establish best practices in the industry.
If you’re new to software supply chains, here is an example of a software supply chain and all of the locations the software could be vulnerable.
So, what is SLSA, if not something you dip your chips in? Let’s start with a definition: SLSA is a security framework for securing a software supply chain against tampering, focused on protecting software from source through when it’s used and letting users make automated decisions about the integrity of artifacts they are using.
The table below describes each level and provides an example of controls implemented at that level. The table is taken from slsa.dev/levels – where you can read the detailed explanation of each level and find the full list of requirements for each level.
Why is this important? Well most of us know, innovation will prosper with a more secure environment. This is especially true within a software supply chain where around 80% of the code is reused from other developers and projects. That re-use is efficient and handy, but only as far as you can trust it. Knowing that you don’t have to worry about the code in your software potentially being vulnerable can make a huge difference.
What makes SLSA different? According to Joshua Lock, until recently there were no public end-to-end descriptions of how to end-to-end secure a software supply chain, because most companies weren’t thinking about the need for security in that setting. Although many companies had internal supply chain security protocols, none of the information was publically available nor spoken about in a conference setting. For others who were thinking about it, the cost of the engineering was far too high for any smaller scale company to consider. After the recent increase in focus on software supply chain security, multiple projects started forming including OWASP’s SCVS (Software Component Verification Standard), Microsoft’s SCIM (System for Cross-Domain Identity Management), and SLSA. SLSA meshed with Lock’s mental model of how software is produced for two reasons.
The first reason is that the encapsulated best practices seemed relatively complete compared to his previous experience, and the second is that the leveling system enables an iterative approach rather than trying to fix a problem overnight. Not only this, but it is important to remember that with all security, trust is crucial, and with SLSA there is evidence generated with policy checks (manual or automated systems) that allow users to verify that the system is working. So, trust and verify. Lock also noted that the SLSA team is looking for contributors of any kind, whether you can participate by reading through it and commenting, or actually contributing code – this project is in the early definition phases, and feedback and questions are extremely welcome.
To learn more about supply chain security and VMware’s work in this space, read our recent blog about OpenSSF where VMware’s CTO, Kit Colbert, discussed tackling Software Security with an Ecosystem Approach. If you’re interested in learning more about SLSA, check out their GitHub and website. If you want to watch the Tom and Joshua’s presentation, here is the recording of the SLSA talk at KubeCon.
