SLSA, pronounced "salsa", is a set of guidelines for securing how software is built and delivered. When a vendor says a product meets a SLSA level, it is describing how protected the build process was against tampering. It is not a statement that the code has no bugs.
What SLSA is
The SLSA site describes it as a set of incrementally adoptable guidelines for supply chain security, established by industry consensus. Software producers can use it to harden their own supply chains. Consumers can use it to judge whether to trust a package. It offers a shared vocabulary, a checklist, and a way to measure progress toward NIST's Secure Software Development Framework.
Note that the version 1.0 pages are marked retired, with a newer version current. Check the current specification before relying on any detail in this post.
What a level means in plain terms
SLSA organizes requirements into tracks and levels. Version 1.0 has a single Build track with Levels 1 to 3. Higher levels give stronger protection against supply chain threats and cost more to put in place. Lower levels are easier to adopt but offer more modest guarantees. "SLSA 0" refers to software that meets no level.
A level claim signals that the producer followed practices that protect against specific kinds of compromise, such as tampering during or after the build.
What SLSA does not cover
The SLSA site is explicit about its limits:
| Not covered | What that means for you |
|---|---|
| Code quality | A high level does not say the developers wrote secure code |
| Producer trust | It does not stop an organization that means to ship malicious software |
| Dependencies | An artifact's level says nothing about the levels of what it depends on |
That last row matters most for buyers. A product built carefully can still contain a component with a known flaw.
How to read a SLSA claim
- Ask which track and which level, and for which product and version.
- Ask where the evidence is, such as a signed build record you can inspect.
- Ask about components inside the product, because the level does not cover them.
- Pair the claim with an SBOM and a vulnerability check.
- Treat the claim as a plus, not a pass.
A fair vendor answer
A good answer names the level, links to the evidence and says what is not covered. A weak one uses the word SLSA as a badge with no detail. If a vendor cannot say which level, that tells you something.
Where Safeguard fits
SLSA speaks to how a build was made. Safeguard speaks to what went into it: dependency scanning, SBOMs, reachability analysis and policies and gates that decide what is allowed to ship. The two answer different questions, and a buyer often needs both. The free scan is at gold.safeguard.sh/scan.
Quick check
Is SLSA a certification?
The SLSA site presents it as guidelines and a checklist, not a certificate. Ask for the evidence behind any claim.
Does SLSA protect me from vulnerable libraries?
No. It does not cover dependencies or code quality. Use SBOMs and vulnerability scanning for that.
Sources
Last reviewed: 19 October 2026.
