SLSA

Expanded Definition

SLSA, short for Supply-chain Levels for Software Artifacts, is a maturity framework for software supply chain integrity. It is used to describe how much assurance exists that a build output came from a known source, was produced in a controlled environment, and has not been tampered with after build time. For NHI Management Group, the practical value of SLSA is that it turns software provenance into an auditable security property rather than a vague trust assumption.

Definitions vary slightly across vendors and open source communities, but the core idea is stable: stronger SLSA levels require stronger source control, build isolation, provenance metadata, and verification. That makes it adjacent to, but distinct from, general DevSecOps and from runtime security controls. SLSA is not a replacement for code review, dependency scanning, or NIST Cybersecurity Framework 2.0; it complements them by answering a different question, namely whether the artifact being deployed can be trusted back to its origin.

The most common misapplication is treating SLSA as a one-time compliance label, which occurs when teams claim a level without maintaining the source, builder, and provenance controls that level actually requires.

Examples and Use Cases

Implementing SLSA rigorously often introduces build-system and release-process constraints, requiring organisations to weigh stronger provenance guarantees against added engineering and operational overhead.

• A platform team signs build provenance so downstream deployments can verify which repository, commit, and builder produced a release artifact.
• An internal software factory isolates builds from developer laptops, reducing the risk that compromised local environments can influence production packages.
• A security team requires provenance verification before artefacts are accepted into a container registry, helping block untrusted or replayed builds.
• A regulated business uses SLSA evidence alongside NIST Cybersecurity Framework 2.0 governance processes to show that release integrity is measured, not assumed.
• An open source maintainer publishes signed attestations so downstream consumers can distinguish official releases from forks, mirrors, or repackaged binaries.

These use cases are especially relevant where software is delivered through CI/CD pipelines, dependency-heavy builds, or shared infrastructure. SLSA does not guarantee that code is free of vulnerabilities; it reduces the risk that a malicious actor can alter what gets built, substituted, or deployed after source review.

Why It Matters for Security Teams

SLSA matters because software supply chain compromise often succeeds by attacking the build and release path rather than the application itself. If security teams do not understand provenance, they may overestimate the assurance provided by repository access controls, static analysis, or artifact scanning alone. SLSA helps teams define which parts of the pipeline must be locked down, which attestations must be retained, and which consumers must verify artifacts before use.

This is also where identity security intersects with software integrity. Build systems, CI runners, signing services, and release automation are all non-human identities in practice, and their credentials, keys, and tokens become high-value control points. Weak NHI governance can undermine SLSA because a compromised service identity can impersonate a trusted builder or signing authority. That makes SLSA highly relevant to teams managing secrets, ephemeral credentials, and release automation trust chains.

Practitioners often encounter the cost of weak provenance only after a suspicious release, dependency poisoning event, or incident review reveals that no trustworthy build evidence existed, at which point SLSA becomes operationally unavoidable to address.