SLSA (Supply-chain Levels for Software Artifacts) can show that an artifact was built by the expected platform from the expected source, with tamper evident records. It does not show the code is free of bugs, that the author was honest, or that its dependencies are safe. Read it as a statement about the build, not about the code.
What SLSA is
SLSA is an incrementally adoptable set of guidelines developed by industry consensus. It gives producers a checklist for hardening build pipelines and gives consumers a way to judge whether an artifact is trustworthy. Version 1.0 of the specification has one track, the Build track, with levels 1 to 3, where higher levels give stronger guarantees at higher cost. The specification site notes that newer versions exist, so check the current one before you write policy.
What it helps with
- Tampering after source control.
- Artifacts not built by the expected platform.
- Threats to the build platform itself.
In practice you get provenance: a signed statement of what was built, from what, by which system. A consumer can verify it before use.
What it explicitly leaves open
The specification is clear about this.
- Code quality: it does not show developers followed secure coding practices.
- Producer intent: it does not address organisations that deliberately produce malicious software, though it can reduce insider risk.
- Source and dependency integrity: the v1.0 Build track does not cover unauthorized source or dependency changes.
- Transitive trust: an artifact's level is independent of the levels of its dependencies.
How that relates to real incidents
An attack where malicious content is committed to a repository by someone with legitimate access would produce a perfectly valid provenance record. The build is genuine. The input was bad. That is why SLSA sits alongside other controls instead of replacing them.
Combining it with other checks
OpenSSF Scorecard checks project practices such as code review, branch protection and signed releases. Together, project health plus build provenance covers more of the chain than either alone.
A practical way to adopt it
- Ask your own builds to produce provenance first, since you control them.
- Verify provenance for the few third party artifacts that publish it.
- Record in your inventory which components have it.
- Do not block on it for everything. Most open source does not provide it yet.
Safeguard covers the inventory and prioritisation parts of this with SBOM and dependency scanning and reachability analysis, and you can try a free scan at gold.safeguard.sh/scan. Autonomous remediation with fix PRs is off by default, and every category starts on Manual, so a person approves changes.
Quick check
Does a SLSA level mean a package is secure?
No. It means the build process meets certain tamper resistance guarantees. The code can still be flawed.
Is SLSA a certification?
It is a framework of guidelines and levels, not a certification issued to a company by the specification itself.
Sources
Last reviewed: 19 October 2026.
