SLSA Framework

Speaker: 00:03
Right.

Speaker 2: 00:04
Or maybe you’re deploying a new software tool for your company’s network. You are downloading it directly from a perfectly legitimate vendor. You see their familiar logo on the screen, you trust their brand implicitly, and you know, everything looks completely normal.

Speaker: 00:19
Exactly. It looks safe.

Speaker 2: 00:20
But what if the code itself was entirely poisoned before it ever even reached you?

Speaker: 00:25
Yeah.

Speaker 2: 00:25
Between 2019 and 2022, software supply chain attacks increase by a staggering 742%.

Speaker 1: 00:32
It’s it’s a massive jump.

Speaker 2: 00:34
Right. And that is according to comprehensive research from Sonotype. That statistic tells us that the digital supply chains we all rely on every single day are actively under siege.

Speaker 1: 00:45
It is um it’s a terrifying reality to wake up to. We aren’t just talking about hackers trying to brute force their way through a company’s front door anymore. The tactics have evolved completely.

Speaker 2: 00:55
They’re going around the door.

Speaker 1: 00:56
Exactly. Adversaries are now sneaking into the digital factories that actually build the doors, and they are compromising the locks before those doors are ever even installed on a house.

Speaker 2: 01:06
Which makes traditional security feel a bit like guarding an empty vault, and that is what we are focusing on today. We have a really fascinating stack of sources to guide us through this landscape.

Speaker: 01:16
We do.

Speaker 2: 01:17
We’re looking at a highly detailed, newly published February 2026 guide by security research writer Varoon Kumar. It’s titled SLSA Framework: the Definitive Guide for Securing Your Software Supply Chain. And alongside that technical deep dive, we are also looking at a catalog for DevSecOps certifications.

Speaker 1: 01:37
Yeah, that catalog is it’s eye-opening.

Speaker 2: 01:39
It really is. It gives us this incredible behind-the-scenes look at the exact security skills the tech industry is desperately scrambling to acquire right now.

Speaker 1: 01:47
Aaron Powell The contrast between Varin Kumar’s theoretical security framework and the uh the immediate practical market demand shown in that training catalog is very revealing. It shows an industry in the middle of a massive paradigm shift.

Speaker 2: 02:01
So the mission for this deep dive is to demystify how organizations are actually fighting back against these invisible supply chain attacks. We’re going to explore this framework called SLSA, figure out how it works under the hood, and understand what it means for anyone who builds, buys, or uses software today. Okay, let’s unpack this.

Speaker 1: 02:21
To really understand the immense value of this framework, we have to first understand why supply chain attacks have become the absolute preferred vector for sophisticated adversaries.

Speaker 2: 02:30
Aaron Powell Why are they doing this instead of normal hacking?

Speaker 1: 02:33
The simple answer comes down to the extreme interdependence of modern software. I mean, almost no one writes a complex program entirely from scratch anymore.

Speaker 2: 02:42
Right. That would take years.

Speaker 1: 02:43
Decades in some cases. Instead, developers rely on third-party libraries, open source code, various build tools, and shared cloud infrastructure. Wiz research actually highlights that this interconnectedness creates a massive cascading effect.

Speaker 2: 02:57
A domino effect.

Speaker 1: 02:58
Exactly. If an attacker manages to compromise just one widely used component, that single isolated breach can cascade downstream through thousands of different applications.

Speaker 2: 03:08
It’s the ultimate leverage for a bad actor. Why spend months trying to hack a thousand different companies individually when you can just hack the one tool they all use to build their software?

Speaker 1: 03:19
That is the exact calculus these adversaries are using. Let’s look at the SolarWinds attack in 2020, because it is the textbook example of this nightmare scenario.

Speaker 2: 03:28
Yeah, that was huge.

Speaker 1: 03:29
It was devastating. Attackers compromised the build system for SolarWind’s Orion platform. They essentially injected a backdoor, which became known as Sunbur est, directly into what were supposed to be legitimate software updates.

Speaker 2: 03:42
And the most terrifying part of that SolarWinds breach was that it went completely undetected for months.

Speaker 1: 03:48
Months.

Speaker 2: 03:48
The malicious code was actually signed with SolarWind’s own legitimate cryptographic certificates. For anyone listening who might not be deep into cryptography, a certificate is basically the digital ID badge that tells your computer, yes, this software genuinely came from this company and it is safe to install. Because the hackers had access to the build system, they stamped their malware with that trusted ID badge. More than 18,000 organizations, including major U.S. government agencies, installed that compromised update thinking it was totally safe.

Speaker 1: 04:21
That perfectly illustrates the sheer danger of a compromised build environment. But it’s not the only vector we need to worry about. Consider the massive log four shell vulnerability that broke the internet in 2021.

Speaker 2: 04:34
Oh, I remember that one.

Speaker 1: 04:35
That vulnerability affected millions of applications globally. But the real underlying issue was that most development teams didn’t even know they were exposed. Log4J was what we call a transitive dependency.

Speaker 2: 04:45
Let’s break that down a bit. A transitive dependency is essentially like a Russian nesting doll of Exactly.

Speaker 1: 04:51
A nesting doll of code. Yeah. That’s a great way to picture it. You might build an app and intentionally include library A because you need its features. But library A secretly relies on libraries B to function, and library B relies on library C. Log4J was often library C. It was buried deep inside other dependencies. It was completely invisible to the developers actually writing the end product, let alone the consumers using it.

Speaker 2: 05:14
Then you have attacks that target the actual plumbing developers use to move their code around. The source material mentions the code cov attack in 2021. Attackers modified something called a bash uploader script. A bash uploader is essentially just a little piece of code that automates moving files from one place to another, but by altering that script, the attackers were able to steal CICD secrets.

Speaker 1: 05:37
And we should clarify CI CD for a moment. It stands for continuous integration and continuous deployment. Think of it as the automated conveyor belt in a software factory.

Speaker: 05:45
Okay.

Speaker 1: 05:46
It takes some of the raw code written by developers, tests it, packages it, and deploys it to the servers. The secrets you mentioned are the highly sensitive passwords and digital keys that allow that conveyor belt to access different parts of the network.

Speaker 2: 05:59
So by compromising that one uploader script, they stole the keys to the kingdom. They distributed that compromised script to thousands of organizations for two months before anyone even noticed.

Speaker: 06:11
It’s wild.

Speaker 2: 06:12
And the sources also point to the JetBrain’s Team City vulnerabilities in 2023, where attackers gained administrative control over the actual build infrastructure itself. They own the factory.

Speaker 1: 06:23
When an adversary gains admin control over a CICD server, they potentially compromise any piece of software built through that sister from that moment on. It is quite literally game over for digital trust.

Speaker 2: 06:35
Which brings this reality right back to you, the listener. When you update an app on your device, you are trusting the brand name on that app. You trust your bank, you trust your email provider. But the reality is you are actually putting your trust in a massive, invisible web of tools, libraries, and automated conveyor belts that those brands rely on. If those tools are compromised, you’re compromised.

Speaker 1: 06:55
Which is exactly why the tech industry realized it could no longer rely on blind trust. They had to create a standardized, verifiable way to prove that software hasn’t been tampered with anywhere along that supply chain.

Speaker 2: 07:08
So how does the industry actually fix a problem this massive? The source material points to a framework called SLSA. It is spelled SLSA, but the industry pronounces it salsa.

Speaker 1: 07:19
The origin story of SLSA is quite telling. It wasn’t just theorized in an academic vacuum. Google originally developed it based on an internal system they call binary authorization for Borg.

Speaker: 07:29
Right.

Speaker 1: 07:29
Google realized this problem years ago and actually made this system mandatory for all their internal production workloads for over eight years. Recognizing that the entire global industry needed this exact same protection, they contributed the framework to the Open Source Security Foundation, or OpenSSF, back in 2021. Today we are looking at version 1.1 as the stable release with 1.2 in active development.

Speaker 2: 07:53
But we need to be really clear about what SLSA actually is, because it is not a piece of software you can just buy off the shelf and install. It’s not an antivirus scanner that looks for malware.

Speaker 1: 08:02
That is a vital distinction. SLSA is a security framework. It is a set of rules and standards. Its primary purpose is to provide what the industry calls provenance.

Speaker 2: 08:13
Provenance.

Speaker 1: 08:13
Yes. Provenance is essentially tamper-evident metadata that answers three critical questions about any piece of software. Who built it, what source code and dependencies were used, and exactly how was it built. This metadata is structured using a specific machine readable format called Intoto.

Speaker 2: 08:31
I love the analogy the source material uses to conceptualize this. In software security, you hear a lot about an S-bomb, a software bill of materials. Right. An SBOM is basically the ingredient list on the back of a box of food. It tells you exactly what is inside the package. But SLSA, SLSA is the food safety certification that proves the factory where the food was made wasn’t contaminated. It doesn’t just list the ingredients, it proves the entire manufacturing process was clean and secure.

Speaker 1: 08:57
What’s fascinating here is how the framework scales. Google and the OpenSSF knew they couldn’t expect every organization to achieve perfect airtight security overnight. That would paralyze the industry.

Speaker 2: 09:08
Nothing would ever get shipped.

Speaker 1: 09:10
Exactly. Instead, SLSA defines progressive maturity levels. It breaks the journey of securing the supply chain down into highly specific, achievable steps.

Speaker 2: 09:21
Let’s walk through those steps because understanding these levels really paints a picture of how the tech industry is trying to dig itself out of this massive hole. We start at the bottom, which is level zero.

Speaker 1: 09:31
Level zero is essentially the Wild West. There is absolutely no provenance. You have zero verifiable evidence of how a software artifact was actually built.

Speaker 2: 09:41
None at all.

Speaker 1: 09:41
Unfortunately, this is the default state for the vast majority of software in the world today. If a company is operating at level zero, they cannot detect tampering in their build process, and they cannot definitively verify where a compiled piece of software actually originated. Right, no manual steps.

Speaker 2: 10:07
That means you can no longer have a human developer manually typing commands into a terminal to build the code. It has to be automated. Furthermore, the build platform has to automatically generate that metadata we talked about. Things like cryptographic hashes of the output, the source repository location, timestamps, and a list of the dependencies used.

Speaker 1: 10:27
It is a vital first step for visibility, but level one has a massive glaring limitation. At level one, that provenance metadata is not find. That means an attacker who gains access to the build system can simply forge the metadata. Level one protects a company against accidentally distributing the wrong package, and it provides some basic traceability if an incident occurs, but it operates on a huge assumption. It assumes your build platform is totally trustworthy without actually validating that assumption cryptographically.

Speaker 2: 10:59
Which means someone could just write up a fake receipt for the software. To fix that, we have to level up again. But level two is where we get into signed provenance and hosted builds. At this stage, the build can’t just happen on some random developer’s local laptop sitting in a coffee shop. It has to run on a dedicated, secure, hosted build service. And more importantly, that metadata receipt we just talked about, it now has to be cryptographically signed by the build platform itself.

Speaker 1: 11:24
This is where we start seeing real security. Level two prevents provenance forgery after the build completes. Because it is signed by the hosted service, it guarantees the metadata hasn’t been maliciously altered in transit since it left the build server.

Speaker: 11:53
It was a mess.

Speaker 2: 11:54
So how does SLSA handle that signing without creating a massive headache?

Speaker 1: 11:58
They solve it using an ingenious standard tool chain called Sigstore, which enables what the industry calls keyless signing. Instead of a developer keeping a highly sensitive, long-lived cryptographic key on their machine, which, as you noted, is easily stolen or mishandled, they authenticate their identity using an OIDC identity provider.

Speaker 2: 12:17
And just to clarify OIDC, that is basically the standard protocol behind those buttons you see everywhere that say login with Google or login with GitHub, right?

Speaker 1: 12:26
Precisely the same mechanism. You log in with your verified identity, and Sixdoor handles all the complex cryptography in the background using three main components.

Speaker 2: 12:34
Okay, what are they?

Speaker 1: 12:35
First is Cosign, which is the tool that actually signs and verifies the software artifacts. Second is Fulsio, which takes your login identity and issues a short-lived digital certificate tied specifically to that session. And third is Raycore.

Speaker: 12:48
Raycore.

Speaker 1: 12:48
Raycor is brilliant. It is an immutable transparency log. Think of it as a public notary’s logbook that permanently records the signing event so it can be audited later, but cannot be erased or altered.

Speaker 2: 12:59
So Sixdoor makes it incredibly secure and user-friendly, but we still aren’t at the top of the mountain. Because even with level two securing the metadata after the build, what is stopping a hacker from just messing with the code during the actual compilation process on that hosted server?

Speaker 1: 13:15
And that is the exact vulnerability level three addresses. Level three is called hardened builds, and it is the ultimate defense in the framework. It requires completely isolated build environments. That means every single software build runs completely independently of any other build. Even more critically, it requires ephemeral environments.

Speaker 2: 13:35
Ephemeral meaning they vanish. It’s like having a bank vault that magically constructs itself around your specific transaction, processes the money, and then completely evaporates into thin air at the second you are done.

Speaker 1: 13:47
That is an excellent way to visualize it. The build environment is provisioned fresh from an absolute blank slate for every single build. Once the software is compiled and the prominence is signed, the environment is completely destroyed, wiped clean. Furthermore, the signing keys used by the build platform are kept totally inaccessible to any of the user-defined build steps. This architecture prevents cross-build contamination, stops insider threats from altering the environment, and prevents any tampering during the execution phase.

Speaker 2: 14:16
Let’s do a little alternate history here to make this concrete. Think back to that massive solar winds attack that impacted 18,000 organizations. If solar winds had been fully operating at SLSA level three, what would have happened to the Sunbar S backdoor?

Speaker 1: 14:33
The attack almost certainly would have failed. The attackers relied on persisting within the build environment over a long period. SLSA level three’s isolated builds would have prevented them from accessing other parts of the system.

Speaker 2: 14:45
Because it’s isolated.

Speaker 1: 14:46
Right. And the ephemeral nature of the environments would have destroyed any footholds they tried to establish immediately after each build finished. The isolated signing keys would have made it computationally impossible for their compromised code to forge the provenance document.

Speaker 2: 15:00
So they’d be stuck.

Speaker 1: 15:02
Completely stuck. Ultimately, the provenance verification process would have flagged that the final compiled software artifact didn’t mathematically match the expected legitimate source code commits. The system would have stopped the praisened update from ever being distributed.

Speaker 2: 15:18
Building those disappearing bank vaults sounds incredibly complicated, though. You are talking about completely re-architecting how a company creates its products. Who actually knows how to implement this stuff? Which brings us to a really fascinating human element in our sources today: the massive boom in DevSecOps training.

Speaker 1: 15:37
The industry is acutely aware of the danger, and they are also acutely aware of the massive skills gap. Organizations are in a state of near panic, actively scrambling to train their engineering teams to implement these exact frameworks.

Speaker 2: 15:50
Looking at this DevSecOps training catalog from our sources, you don’t even need to look at the syllabus to understand the market demand. The prices alone tell a story about how highly valued these skills are right now.

Speaker: 15:60
They really do.

Speaker 2: 16:00
This catalog is running a year-end sale, and you have the Certified Software Supply Chain Security Expert course, which explicitly teaches SLSA and how to defend against dependency confusion selling for $799. You have their certified AI Security Professional course, which is flagged as a bestseller, going for $10,000 and $99. Companies are throwing thousands of dollars at this just to get their teams a baseline understanding.

Speaker 1: 16:25
And the catalog pushes these massive bundles, pairing foundational DevSicOps training with these highly specialized supply chain certifications, offering enterprise savings up to $498. It highlights a broader shift. Supply chain security is no longer a niche academic specialty relegated to a single security engineer in the basement. It is rapidly becoming a mandatory core competency for anyone working in enterprise IT.

Speaker 2: 16:50
So if an organization buys into this training and they commit to securing their factory, what is the actual on-the-ground reality of implementing SLSA? How much pain are we talking about and how long does it take?

Speaker 1: 16:59
The roadmap the Rune Kumar outlines is practical, but it requires serious patience and a willingness to endure organizational friction. Implementing this means fundamentally changing developers’ daily workflows, which always causes pushback. Phase one, achieving that foundational level one visibility, typically takes an organization one to four weeks. It is mostly an auditing exercise, finding out where developers are manually compiling code and forcing everything into automated scripts. Phase two, moving to level two and implementing that six-store cryptographic signing, is a heavier lift. That takes about five to twelve weeks of engineering time.

Speaker 2: 17:37
And getting to phase three, the ephemeral hardened builds.

Speaker 1: 17:40
That is easily a three to six month journey for most enterprise organizations. It requires massive infrastructure changes. You are essentially rebuilding the airplane while it is flying.

Speaker 2: 17:49
Yeah, that’s not easy.

Speaker 1: 17:50
And it is worth noting that not all cloud platforms are created equal in this regard. The source material explicitly points out that Azure DevOps currently lacks native built-in SLSA support. Yes, if a company’s infrastructure relies heavily on Azure, they will have to invest in third-party tools or build highly complex custom implementations. Organizations are generally advised to migrate to platforms like GitHub Actions or Google Cloud Build for their most critical SLSA compliant workloads, because those platforms have this capability baked in.

Speaker 2: 18:21
So what does this all mean? Let’s say a company spends six grueling months, they fight through all the friction, and they finally hit level three. Does that mean their software is perfectly impenetrably safe?

Speaker 1: 18:33
No, it doesn’t. And that is a critical blind spot that both the industry and consumers need to understand. SLSA is incredibly powerful for its specific use case, but it has distinct limitations. First, SLSA does absolutely nothing to check the actual quality of the code being written. It doesn’t scan for CVEs.

Speaker 2: 18:50
And for context, CVEs are common vulnerabilities and exposures, basically a public dictionary of known software bugs and flaws.

Speaker 1: 18:58
Exactly. SLSA only proves that the final software artifact was built exclusively from a specific set of source code. It does not prove that the source code itself is safe, well written, or free of vulnerabilities.

Speaker 2: 19:08
That’s a huge point.

Speaker 1: 19:10
If a developer writes terrible, highly vulnerable code, a level three SLSA system will perfectly verify, sign, and securely deliver that terrible, vulnerable code.

Speaker 2: 19:21
It’s securing the delivery truck, but it doesn’t inspect the cargo to see if it’s broken.

Speaker 1: 19:25
Second, SLSA offers zero runtime security. It covers build time integrity, but once the software is actually installed and running on a server or a phone, you still need robust network policies and runtime monitoring to detect malicious behavior.

Speaker: 19:39
Right.

Speaker 1: 19:40
And third, it does not automatically verify your third-party dependencies unless those external dependencies also use the SLSA framework and provide their own signed provenance.

Speaker 2: 19:50
It requires the whole ecosystem to participate.

Speaker 1: 19:52
If we connect this to the bigger picture, it means SLSA cannot exist in a vacuum. It is a structural foundation, but it must be paired with other specific security tooling. Organizations still need SAS tools, DS tools, and SEA tools to be genuinely secure.

Speaker 2: 20:07
Let’s translate that alphabet soup for a second. SAST is static application security testing. That is basically running a really advanced spell check on the raw code as the developer types it, looking for known bad patterns. Yes. DAST is dynamic application security testing. That is more like a crash test dummy that actively attacks the application while it’s running to see what breaks. And SCA is software composition analysis, which scans all those third-party dependencies we talked about to see if you are accidentally using expired or recalled ingredients.

Speaker 1: 20:37
That is a perfect summary. SLSA is the factory certification, but you still need the spell check, the crash test dummy, and the ingredient inspector. It is one critical piece of a much larger defense-in-depth puzzle.

Speaker 2: 20:50
To wrap this all up, SLSA is fundamentally about verifiable proof of build integrity. Whether you are a developer who needs to mathematically lock down the dependencies you are pulling into your projects, or you are an enterprise buyer evaluating software vendors before you sign a massive procurement contract, verifiable provenance is rapidly moving from a nice-to-have feature to the absolute bare minimum standard.

Speaker 1: 21:12
This raises an important question, though, and it touches on the very limits of what technology can actually solve. We’ve established that SLSA perfectly verifies the delivery mechanism. It ensures the software wasn’t tampered with by a hacker anywhere along the automated conveyor belt. But there is a massive limitation noted in the research regarding what they call malicious producers. SLSA operates entirely on the assumption that you trust the source organization.

Speaker 2: 21:38
Wait, I’m looking at this malicious producer limitation now. If SLSA only verifies the delivery, what happens if the developer themselves is the bad actor? What if you trust the company, but an employee inside that company goes rogue?

Speaker 1: 21:52
That is the ultimate vulnerability. What is a fully verified, authenticated, authorized developer intentionally writes malicious code from the very Start. Perhaps they are a disgruntled employee, or perhaps they have been blackmailed by a nation state.

Speaker 2: 22:05
Yeah, that happens.

Speaker 1: 22:07
SLSA will do its job perfectly. It will securely compile that code, cryptographically sign it, and deliver that poison with a verified, level three stamp of approval. Yeah. SLSA uses brilliant mathematics to prove the software wasn’t tampered with during delivery. But how do we, as a tech society, build a framework to verify the actual intent of the human being sitting at the keyboard in the first place?

Speaker 2: 22:29
That is a mind bending thought to chew on. Cryptography and ephemeral bank vaults can flawlessly verify the factory process, but they absolutely cannot verify the human heart. We’re going to leave you with that to think about. Thank you for joining us for this deep dive into the SLSA framework, and as always, keep questioning the digital world around you.

Practical DevSecOps (a training division of Hysn Technologies Inc) provides world-class, practical, and hands-on Product Security training and certification programs. Our state-of-the-art online lab ensures our students learn the practical aspects of the course and showcase their knowledge to employers and colleagues with world-renowned Certifications.