SLSA

What it is #

SLSA (pronounced “salsa”, short for Supply-chain Levels for Software Artifacts) is an industry-consensus framework that defines incrementally adoptable levels of supply-chain security and the attestations that demonstrate compliance with each level. SLSA v1.2 organises requirements into two tracks.

Build Track (L1-L3). Attests how an artefact was built. L1 requires provenance to exist, but it may be unsigned and forgeable. L2 requires signed provenance from a hosted build platform. L3 requires the build platform itself to be hardened against tampering during the build (build isolation, unforgeable signing).

Source Track (L1-L4). New in v1.2. Attests how a source revision was created and what controls the source control system enforced. L1 requires a version control system. L2 requires continuous, immutable history plus contemporaneously-generated Source Provenance attestations. L3 requires continuously-enforced organisational technical controls. L4 requires two trusted persons to review every change to protected branches.

Both tracks emit attestations in the in-toto Attestation Framework format, typically wrapped in DSSE and signed using Sigstore or a long-lived key.

Trust model #

SLSA itself is a specification, not a trust anchor. The trust anchor depends on the deployment: for the Build Track, it is the build platform’s signing identity (often a Sigstore-bound OIDC identity for a CI workflow); for the Source Track, it is the Source Control System issuing Source VSAs and Source Provenance attestations (GitHub, GitLab, gittuf, and so on).

What SLSA attests is process: which platform built an artefact, which controls were enforced when a source revision was produced, who reviewed which changes. The specification is explicit that SLSA does not cover code quality (“SLSA does not tell you whether the developers writing the source code followed secure coding practices”), nor transitive trust in dependencies (an artefact’s level is independent of its dependencies’).

Comparison to OpenVet #

SLSA and OpenVet make different kinds of claims about software, and the SLSA specification draws the boundary between them explicitly.

What is being attested. SLSA attests process: how the artefact was built, how the source revision was produced, what controls the platform enforced. OpenVet helps you make attestations about the code itself: whether it is malicious, whether it is implemented correctly, whether there are findings consumers should know about. SLSA’s “About” page is explicit that code quality is outside SLSA’s scope.

Granularity. A SLSA level applies to a single artefact and says nothing about its dependencies; this is intentional. OpenVet’s claims are also per-package: a consumer composes claims from many audits, one per dependency, into the requirements declared in openvet.toml. Both systems leave transitive evaluation to the consumer.

Trust set. SLSA inherits the trust roots of whatever signing scheme its attestations are wrapped in (Sigstore for most public deployments, long-lived keys for some internal deployments). OpenVet consumers list one or more log URLs in openvet.toml, each independently signed by its owner.

Source Track vs source audit. SLSA Source Track L4 requires two-party review of changes, which sounds adjacent to “someone read the code”. The attestation is about whether the review happened and what controls enforced it, not about what the reviewers found. An OpenVet audit captures the latter: structured claims asserted by an identified auditor about specific code.

Using alongside OpenVet #

SLSA attestations and OpenVet audits compose at audit time, not at consumer evaluation. The composition story differs across SLSA’s two tracks.

Binary attestations as audit evidence. Where an audit touches a compiled binary, vendor-shipped library, or model weights, the auditor cannot read the artefact meaningfully but can verify any SLSA Build provenance attached to it and re-surface what was verified as an OpenVet claim. A verified SLSA Build attestation does not say the binary is benign or correct; it records who built it, on what platform, from which source revision. That is concrete attribution evidence an audit can carry forward, particularly useful when investigating after the fact.

Source attestations are largely orthogonal to source audit. SLSA Source Track attestations describe the process that produced a revision: whether code review was enforced, whether history is immutable, whether the SCS prevented force-pushes. An OpenVet audit looks at the resulting source code directly, records the VCS provenance of what it reviewed (commit hash, repository URL) inside the audit itself, and asserts claims about the content. The two target different layers of the same revision, and process attestations do not change what is in the code.

Where SLSA and OpenVet don’t overlap. SLSA’s specification is explicit that it does not say whether the code is correct or safe. OpenVet is explicit that it does not attest to the build process or to the controls that produced a revision. Each fills the gap the other declares out of scope.