Safeguard.sh
← Concepts & Glossary
Inventory & Provenance

SLSA Provenance

Signed attestations that prove how a build artifact was produced.

What is SLSA provenance?

SLSA (Supply-chain Levels for Software Artifacts) is an OpenSSF framework for proving, cryptographically, that a build artifact came out of a specific pipeline running specific source code on a specific builder. Provenance is the signed document that carries that evidence.

Provenance is typically expressed in the in-toto attestation format: a JSON payload that names the artifact by hash, lists the source repository and commit, names the builder, and is signed (commonly via Sigstore / Fulcio / Rekor). A consumer verifies the signature, checks the source and builder against policy, and only then trusts the binary.

How it works

SLSA defines four levels of assurance, each adding controls that close a specific class of supply-chain attack:

  1. Level 1 — documented build. The build process is scripted and produces provenance, but the provenance is not cryptographically verified. Baseline for visibility.
  2. Level 2 — signed provenance on a hosted builder. Provenance is generated and signed by a hosted build service (e.g. GitHub Actions with the SLSA generator). Tampering with the provenance is now detectable.
  3. Level 3 — hardened builder, non-falsifiable provenance. The builder is isolated so build steps cannot forge provenance about themselves. Source and dependencies are version-controlled. This is the level most enterprises target.
  4. Level 4 — two-party review and hermetic builds. Every change is reviewed; builds are hermetic and reproducible. Very high assurance, achievable mainly on greenfield pipelines.

Why it matters

SolarWinds, 3CX, and Codecov all shipped clean-looking source code and still compromised downstream customers — because the build pipeline itself was modified. Reviewing the source only tells you about one attack surface. SLSA provenance closes the other one.

Provenance also gives consumers a cryptographic answer to "did this binary really come from the repo you claim?" That answer is increasingly a procurement requirement, a CRA expectation, and — for anyone serving US federal customers — a matter of attestation under EO 14028 / M-22-18.

What value it adds

  • Prevents build-pipeline compromise

    A SolarWinds-style attack that modifies the builder is detectable — the resulting provenance does not match your policy and the binary fails admission.

  • Cryptographic link from source to artifact

    Every deployed binary can be traced back to a specific commit, builder run, and reviewer — without trusting the producer's word for it.

  • Federal and enterprise procurement fit

    EO 14028 attestation and tier-1 enterprise supplier questionnaires increasingly expect signed provenance. Shipping it is cheaper than explaining why you do not.

  • Defensible admission controls

    Kubernetes admission policies and Cosign verification can reject any artifact without matching provenance — a real, enforceable supply-chain gate.

  • Composable with SBOM and VEX

    Provenance, SBOM, and VEX together form the evidence bundle that regulators are converging on. Same infrastructure, compounding value.

How Safeguard uses it

Safeguard generates, stores, and verifies SLSA provenance as part of SBOM Studio and the supply-chain compliance workflow. Provenance sits alongside SBOMs as part of each product's evidence bundle.

SBOM Studio →Supply-Chain Compliance →SBOM →

Ship signed provenance per build.

Point Safeguard at a pipeline. Generate, store, and verify SLSA-compliant attestations for every artifact.

Book a walkthroughBrowse all concepts