When you hear “salsa”, the first thing that comes to mind is likely dancing or your favorite Mexican restaurant. But in relation to software security, SLSA (supply-chain levels for software artifacts) is fundamental to the rhythm that keeps your deployments safe.
What is SLSA?
The official SLSA website defines SLSA as follows:
“SLSA is a set of incrementally adoptable security guidelines, established by industry consensus. The standards set by SLSA are guiding principles for both software producers and consumers: producers can follow the guidelines to make their software more secure, and consumers can make decisions based on a software package’s security posture. SLSA’s four levels are designed to be incremental and actionable, and to protect against specific integrity attacks. SLSA 4 represents the ideal end state, and the lower levels represent milestones with corresponding integrity guarantees.”
SLSA explained - secure your software supply chain now
What problem does SLSA solve?
Modern software relies heavily on dependencies, which amplifies the need to ensure software integrity from build through to deployment.
Steve Fenton described his current experience of creating software as, ‘I would guess most of the software that I publish these days. There are more lines of code that came from somewhere else than came from me.”
In simple terms, if you publish version 1.2 of your software, you want to make sure you know what’s included in that version and that when people install version 1.2 it’s the same version 1.2 that you published. So how do you keep tabs on everything baked in and ensure your software version hasn’t been tampered with?
That’s where SLSA comes in as a very popular set of guidelines and a pathway to making things secure.
Key concepts of SLSA
Some of the key terms you will hear used around SLSA are provenance and attestation. These can be defined as:
Provenance: The metadata about how your software was built. In Bob’s baking analogy, this is the exact list of instructions to follow to make the cake.
Attestation: The guarantee that the software was built according to what is laid out in the provenance. The baking analogy is the official sign-off that the cake was baked exactly as the instructions outlined.
SLSA explained - enhance your supply chain security
Bob called out another key part of the puzzle when dealing with supply chain security, SBOMs (software bill of materials), “But I also want to make sure we address SBOMs as well. Because to me that’s all crucial to your supply chain security.‘
Understanding SBOMs
What is an SBOM? A typical explanation is that an SBOM is a formal list of all the components and dependencies that comprise an application. Steve kept us on the catering theme with his explanation.
“The catering examples are great for this, especially as it’s SLSA. Right? So if I was making a salsa, and I claim it’s a vegan salsa, right. Cool. Got my market in mind. It’s Tony and I would need to make sure that everyone that I got my ingredients from was supplying me with vegan ingredients.
“And they would give me a batch number, and I would take all those batch numbers. I would create a list of ingredients that I’ve put in, have those batch numbers, and have those suppliers listed. So I know where everything came from. So if anyone were to challenge my vegan recipe, I’ve got the list of things that I use to make it, which helps me prove that it’s all vegan. That effectively is my SBOM for my salsa.”
SLSA levels explained
We’ve established that SLSA is a set of incrementally adoptable security guidelines. There are 4 official levels, although level zero is a thing. Bob explains, ‘And if you opt for salsa level zero, which basically means no, no protection whatsoever in the supply chain, you will have…I won’t necessarily call it fun, but it will be exciting, because of all the exploits you’re exposing yourself to.‘
SLSA level 1: Automating the foundation
SLSA level 1 establishes automation and generates provenance metadata - the “recipe” for how your software was built. Your CI/CD platform automatically documents what source code, dependencies, and build steps were used.
If you’re using modern tools like GitHub Actions or Jenkins with automated builds, you’re likely already here. While level 1 doesn’t verify anything yet, it creates the auditable foundation needed for higher levels.
SLSA level 2: Making It official
Level 2 adds cryptographically signed attestations to your build metadata. Your build server now makes a tamper-proof statement: “I built this artifact using these specific inputs and steps.” This signature can’t be forged; any tampering breaks it immediately.
Most modern hosted build services can generate and sign attestations with minimal configuration, making level 2 straightforward to achieve.
SLSA level 3: Verification in action
Level 3 shifts to active defense by verifying attestations before deployment. Your deployment system checks that the artifact’s hash matches a valid attestation from your official build system. If verification fails, deployment stops automatically.
This security checkpoint blocks unauthorized or tampered artifacts before they reach any environment, ensuring every deployment starts with a known-good, verified artifact.
SLSA level 4: The gold standard
Level 4 requires two-person code review (enforced through pull request policies) and hermetic, reproducible builds that produce identical outputs from identical inputs. If you’re already using required PR reviewers and building within containers using versioned dependencies, you may already qualify.
The major benefit is the positive compliance knock-on effect. Level 4 aligns with SOX, ISO 27001, and SOC 2, checking multiple regulatory boxes simultaneously.
SLSA level 4 - Achieve security through automation
Scaling SLSA with Platform Hub
Let’s talk about how Process Templates and Policies can improve your SLSA implementation process and compliance.
Process Templates mean every team in your organization doesn’t need to figure out SLSA independently. Platform teams can create reusable templates that include necessary verification steps directly into deployment processes with just a few parameters.
The real benefit happens when regulations change or your compliance requirements means you need to add additional layers of verification. With Process Templates you can update the central template and push those changes out to all teams, with everyone inheriting the improvements automatically.
The addition of Policies gives you a mechanism to check and enforce critical updates across all pipelines. With policy enforcement, you can verify that teams are using the up-to-date template, issue a non-compliance warning for a specified period, and block deployments for non-compliance if necessary.
The ultimate goal is to achieve organization-wide SLSA compliance without having to coordinate updates across hundreds of individual teams.
Process Templates - simplify container deployments and compliance
Useful links and bonus content
Throughout this episode, we mentioned a bunch of tools and resources that I have linked below:
Our bonus round question this week focused on which decade produced the best music. The answer was a resounding vote for the 90’s. Partly driven by nostalgia, but Bob Walker also gave an insight into his working theory on why the 90’s produced the best music.
Check out the video below to catch the full episode.
Happy deployments!
