You can have a completed questionnaire on file for every supplier and still not be able to answer a simpler question about the software running in your environment: where did this build actually come from, and can you prove it?
Most organizations cannot. They can name the vendor. They can produce a contract. What they cannot produce is evidence, checkable by a third party, that a specific artifact was built from a specific commit by a specific pipeline. That gap is where some of the most damaging incidents of the last several years lived, and it now has a standard aimed squarely at it.
SLSA in plain English
SLSA stands for Supply-chain Levels for Software Artifacts. It is pronounced "salsa," it is maintained under the Open Source Security Foundation, and the current version is v1.2.
It does one thing: it makes the origin and build process of a piece of software checkable. Not documented, not asserted in a questionnaire. Checkable.
The mechanism is a document called provenance. When your build system produces an artifact, it also emits a signed statement describing what it just did: which source repository, which commit, which workflow, which builder, which inputs. The statement is bound to the artifact by cryptographic digest, so it cannot be moved to a different file. Anyone who receives the artifact can verify the signature and read the claims.
The framework organizes requirements into two tracks. The Build track covers how the artifact was produced, rising from provenance that merely exists, to provenance that is signed and authentic, to provenance the build itself cannot forge. The Source track, new in v1.2, covers how the code got into the repository in the first place: version control, history that cannot be quietly rewritten, controls that stay on, and two-party review.
Levels are not a grade for your company. They apply per artifact, per track. A single organization can have one service at the top of the Build track and another with nothing at all.
The part that most programs get wrong
Here is the thing worth understanding before you fund any of this.
Generating provenance changes nothing on its own. It is a claim sitting in storage. The value appears only when something verifies that claim and refuses what does not match. A pipeline at the lowest build level with a real gate in front of deployment refuses more bad artifacts than a pipeline at the highest level with no gate at all.
This is the most common way a supply chain program fails. An organization spends two quarters producing beautiful, signed, unforgeable provenance, reports a level to leadership, and never turns on anything that can say no. The reporting looks excellent. Nothing has been prevented.
Who needs to know about this
- Anyone selling software to the federal government. CISA's Secure Software Development Attestation Form asks software producers to attest that they follow secure development practices drawn from NIST's Secure Software Development Framework, SP 800-218. Those practices include protecting build environments and maintaining provenance data for the components you ship. SLSA is the most mature, most tool-supported way to actually do what you are attesting to, rather than describing it in a policy document and hoping the question never gets specific.
- Anyone buying software and carrying the risk. If you assess vendors, provenance gives you something better than a questionnaire response. "Can you provide signed build provenance for the release we are deploying?" is a question with a verifiable answer, and the answer tells you a great deal about the maturity of the supplier regardless of what they wrote in their last security review.
- Anyone running the pipeline. Platform engineers, build and release owners, and the security engineers who work alongside them. This group does the work, and this group is who the course below is for.
What SLSA will not do for you
This matters as much as what it does, and it is where I would push back on anyone selling it to you as a complete answer.
SLSA makes origin checkable. It does not make software good. A perfectly verified artifact can contain a critical vulnerability, a dependency with a known CVE, or a backdoor written by someone with legitimate commit access. It does not stop you from depending on the wrong package. It says nothing about what the code does once it is running.
Three attacks in particular walk straight past it: a malicious insider with commit rights, a typosquatted dependency you chose yourself, and unsafe use of a perfectly legitimate library. The framework's own threat documentation is candid about this, and any vendor who is not equally candid is selling something.
Deployed alongside vulnerability management, an SBOM practice you can actually query, and code review, SLSA closes a gap those tools structurally cannot reach. Deployed as a substitute for them, it is an expensive way to feel safe.
The course
I built a fifteen-module course, SLSA for Engineers, for the people who have to implement this.
It runs about ten hours, self-paced. Each module is a single page with the material, worked examples, and a lab. The organizing principle is that every requirement arrives with the attack it prevents, so nobody is memorizing rules. Where an idea is easier to understand by doing, the module lets you do it: step an attacker through forging provenance and watch it verify cleanly at one level and fail at the next; build a verification policy clause by clause and see exactly which bad artifacts still get through; set an enforcement posture and run a week of deployments against it.
Every lab modifies the same sandbox repository, so the pipeline climbs the levels in front of you rather than staying theoretical. The labs target GitHub Actions because that is where most teams are; the requirements themselves are platform-neutral. There is a three-hour fast path for teams who need a working control before they need the full argument, a tooling appendix that isolates the parts of the ecosystem that change fastest, and a checker that scores a real sandbox and tells the difference between what it verified and what you merely claimed.
Module 13 is entirely about what the framework does not cover. That is deliberate. Overselling is the fastest way to lose a room of experienced engineers.
Who should take it
Take it if you configure CI pipelines, own build and release, run a platform team, or advise clients on software supply chain risk. You should be comfortable with git, have set up a pipeline before, and be able to read JSON without effort. No cryptography background is assumed beyond "signatures exist and can be checked."
Do not take it expecting a compliance checklist. It teaches how the controls work and how to prove they are working, which is more useful in an assessment than a mapping table, but it is not organized around a framework crosswalk.
And it is not for your CFO. If you are the person who funds this work rather than the person who does it, this post is your version. Send the course to your engineers.
Three questions to ask your team this week
- For our most recent production release, can we show where it was built and from which commit, in a form a third party could verify?
- If someone pushed an image straight to our registry tonight, would anything stop it from running tomorrow?
- What share of what we deployed last week was verified against a policy that could have refused it?
The first two usually produce a thoughtful answer. The third usually produces silence, and that silence is the finding.
If you want access to the course for your team, or you want to talk through where your pipeline actually stands, get in touch.
