The latest version of the Supply-chain Levels for Software Artifacts (SLSA) framework for improving software supply chain security offers several improvements over the previous version, including better provenance guidelines and a system of "tracks" for implementation.
SLSA 1.0, introduced in April by the Open Source Security Foundation (OpenSSF), depends more on community consensus than does the earlier version. It brings much-needed focus to the framework, especially the new guidance around software provenance — determining the origin, development, ownership, location, and changes to a software artifact or component.
While the provenance improvement is a welcome change, seen as essential to improving security of software during development, it's not focused on software compromises after development, said Matt Rose, Field CISO at ReversingLabs.
"Determining provenance — given the complicated nature of software development in today's world, with cloud-native development and microservices — can be challenging. Everyone works in their own swim lane, so being able to track who does what is very difficult."
—Matt Rose
Here's what you need to know about SLSA 1.0, and how improvements can help reduce software supply chain risk during development.
[ Get eBook: Why Traditional App Sec Testing Fails on Supply Chain Security | See related panel discussion with Richard Bird, Matt Rose, Jasmine Noel ]
What's new in SLSA 1.0
The first version of SLSA was driven primarily by Google, said Kim Lewandowski, co-founder of Chainguard. OpenSSF, which governs SLSA, worked across the broader, extended industry to collaborate on terminology, definitions and more, she said.
"In 1.0, the SLSA working group narrowed the scope of the requirements and put forth in the release the requirements that most of the broader industry worked together on and gained consensus on."
—Kim Lewandowski
One possible drawback for some is that SLSA 1.0 narrows the scope of the framework, said Larry Maccherone, a DevSecOps transformation evangelist at Contrast Security.
"The scope reduction comes from the fact that version 1.0 retains improved versions of the build and provenance areas while leaving out the source and some of the common area requirements.That might be considered a net negative. However, the restructuring should help both with the evolution of the standard and its adoption, which is a net positive, in my opinion.”
—Larry Maccherone
Some of the source and common requirements dropped from SLSA will probably have to be reintroduced into the framework to remain broadly relevant. "But that will require some tradeoffs and a bit of politicking, I suspect," he added.
Chris Hughes, co-founder and CISO of Aquia, said the introduction of tracks was one clear step forward.
"The introduction of tracks to the model now allows for a more focused approach for users of the framework, and lets them focus on specific areas such as source, build, and provenance, versus the more broad-brushed approach of earlier versions."
—Chris Hughes
Get your supply chain security on track
SLSA 1.0 includes incremental levels, or tracks — a prescriptive, progressive set of requirements for build system security. Level one explains how to use a build system, level two describes how to export logs and metadata from the build system, level three introduces more advanced best practices, and level four emphasizes more secure build systems that are purpose-built for software artifact integrity.
"A huge improvement in SLSA 1.0 is the ability to work across different stages in parallel, rather than having to complete each stage in full before advancing to the next stage. They let you know where to get started with software supply chain security and allow you to see the finish line."
—Kim Lewandowski
She described the tracks as a "big workflow improvement" that makes it much easier for development teams "pick off the software supply chain security journey incrementally, rather than all at once within each domain—source, build, and provenance."
Hughes said that breaking SLSA into tracks allows organizations to be more pointed and tactical with their efforts to mitigate risk in the various aspects and activities in the supply chain.
"The tracks allow the framework to be more focused, pointed, and specific to various areas and activities in modern software development, distribution, and consumption. This allows for the tracks to be built out with robust accompanying requirements and specifications so organizations can bolster their security in specific areas such as source, build and provenance, along with the common requirements."
—Chris Hughes
Provenance in the development pipeline
The prior version of SLSA offered guidance on how to produce providence, but no instructions on how to verify it, while the latest version clarifies how to verify provenance across software packages. "SLSA 1.0 really cleans up the model and makes it much clearer how to define provenance," Lewandowski said.
Popular ecosystems like GitHub have already begun to create verification tooling that supports SLSA, which will be critical to its success.
"This is an early sign that SLSA provenance verification is likely to mainstream as good software supply chain security hygiene across all the popular languages and registries."
—Kim Lewandowski
Developers can implement SLSA on code packages on GitHub using actions, making it a very useful tool for development teams.
"SLSA is creating a formalized structure for provenance. It's a step in addressing the who-did-what question in the software supply chain. Without provenance, you can't trust the code in your repo."
—Matt Rose
Provenance in the earlier SLSA versions was treated in a rigid and cumbersome way, said Hughes. With version 1.0, there's a provenance format to help simplify the model and align on common terminology.
"This allows consumers to verify that an artifact is built according to expectations and even rebuild it if desired to verify on their end."
—Chris Hughes
Software supply chain security is a journey
SLSA remains one of the most mature and useful sources of guidance for bolstering software supply chain security, Hughes said.
"It helps standardize terminology, as well as helps organizations align with security levels based on their requirements and desired rigor, and also produces artifacts that can be trusted by downstream consumers."
—Chris Hughes
The SLSA framework is extremely valuable for improving software supply chain security, added Lewandowski.
"This space is so complicated that not knowing where to start is a common problem. That’s what SLSA is designed to address."
—Kim Lewandowski
Jeff Williams, co-founder and CTO of Contrast Security, welcomed the improvements, but cautioned that it's not a comprehensive software supply chain security approach.
“There’s nothing wrong with SLSA. It’s a fairly simple and practical approach to the problem of establishing artifact integrity. The danger is when SLSA starts talking about supply chain security, which is a far bigger frame and requires far more than protection against tampering."
—Jeff Williams
Williams said he worried that organizations will see SLSA 1.0 as the end game on supply chain security, "and spend cycles trying to guarantee artifact integrity before they've included foundational practices like software security testing and runtime protection in their pipelines."
As valuable as SLSA is to the development process, software supply chain security needs to be end-to-end, Rose said.
"All the early stage things are very, very important, but they're not comprehensive. If you think of all the major breaches, many things can happen post-development."
—Matt Rose
