# Provenance and Attestation *An SBOM tells you what's in an artifact. Provenance tells you where it came from and how it was built — a tamper-evident record of the source, the builder, and the steps that produced it. It's the direct answer to the SolarWinds problem: a signed release means nothing if the build itself was compromised, so you need verifiable evidence of the build process, not just the output.* The SolarWinds attack proved that reviewing source code and signing the output isn't enough — if an attacker tampers *during the build*, the malicious artifact is signed and legitimate-looking. Provenance closes that gap by making the build process itself verifiable. This post covers provenance, attestation, in-toto, and the SLSA framework that ties them into levels of assurance. ## What provenance is **Provenance** is verifiable metadata about *how an artifact came to be*: what source code it was built from (repository and commit), who or what built it (the builder identity), what build steps ran, and what inputs went in. It answers "where did this come from and how was it made?" — the question source review and output-signing can't. The crucial property is that provenance describes the *process*, not just the *result*. Signing an artifact (next post) proves *who released it* and that it wasn't altered *after* signing. Provenance proves *how it was built* — which is what catches build-time tampering. Together they cover the whole chain: provenance says "this was built from commit abc123 by our CI, running these steps," and signing says "and it's authentically that artifact, unmodified." You need both, because an attacker who compromised the build could produce a *signed* malicious artifact — but not one with *honest provenance* pointing at the real, reviewed source through an uncompromised builder. ## Attestation: signed statements about artifacts An **attestation** is a signed, machine-readable statement *about* an artifact — an authenticated claim. Provenance is one kind of attestation ("this artifact was built this way"); others include "this artifact passed these tests," "this artifact was scanned and found clean," "this SBOM belongs to this artifact." The model, standardized by the **in-toto** project, is: a *subject* (the artifact, identified by hash), a *predicate* (the claim being made — provenance, test results, SBOM), and a *signature* (proving who made the claim). Because attestations are signed and bound to the artifact's hash, they're tamper-evident and verifiable: anyone can check that the claim really was made by the stated party about *this exact* artifact. This turns supply chain trust into something you *verify* rather than assume. Instead of "I trust this artifact because it's in our registry," you have "this artifact carries a signed provenance attestation showing it was built from our reviewed source by our CI, plus a signed attestation that it passed security scanning" — checkable claims, not faith. Attestations are the machinery that makes "explicit verification over implicit trust" (post 1) concrete. ## in-toto: securing the whole chain of steps **in-toto** is a framework for securing the *entire* software supply chain as a sequence of attested steps. The idea: define the expected steps of your supply chain (checkout → build → test → package) as a *layout*, have each step produce a signed attestation of what it did (inputs and outputs), and then *verify* at the end that the whole chain was executed as defined, by the expected parties, with each step's outputs flowing into the next. This catches tampering *between* steps — if someone modifies an artifact after the build but before packaging, the hashes won't chain and verification fails. in-toto turns "trust the final artifact" into "verify that every step of the process happened as expected and nothing was inserted between them." It's the conceptual backbone under modern provenance, including SLSA. ## SLSA: levels of supply chain assurance **SLSA** (Supply-chain Levels for Software Artifacts, pronounced "salsa") is a framework that organizes these ideas into progressive **levels** of assurance, so you have a roadmap rather than an all-or-nothing target. The levels build on each other, focused heavily on build integrity and provenance: - **Lower levels** establish that provenance *exists* — the build produces a provenance attestation describing its source and process, generated by the build platform. - **Higher levels** harden *how* that provenance is produced — the build runs on a hardened, isolated platform; the provenance is generated by the platform itself (not forgeable by the build steps); builds are increasingly hermetic and tamper-resistant. The value of the level model is that it's a **ladder you climb incrementally**: you don't need perfect supply chain security on day one, you progress from "we generate provenance" toward "our provenance is unforgeable and our builds are hermetic." Each level meaningfully raises the bar against build-time tampering, and it gives you a shared vocabulary ("we're targeting SLSA level N") for measuring and communicating maturity. Crucially, SLSA is about the **build**, because that's the SolarWinds gap: it's designed so that a consumer can verify an artifact was built from the expected source, by a trusted builder, through the expected process — making build-time injection detectable rather than invisible. ## How this fits together Provenance and attestation complete the trust picture the series is assembling: - **SBOM** (post 4) answers *what's in it* — the components. - **Provenance/attestation** (this post) answers *where it came from and how it was built* — the process. - **Signing** (post 6) answers *is it authentic and untampered* — the integrity. All three are signed, verifiable claims bound to the artifact, and together they let a consumer *verify* an artifact's trustworthiness end to end instead of assuming it: what it contains, that it was built from reviewed source by a trusted builder through a defined process, and that it's authentically that artifact unaltered. That verifiable chain — not a signature alone — is what actually defends against the SolarWinds class of attack. The next post covers the signing that binds it all together. ## Key takeaways - **Provenance** is verifiable metadata about *how an artifact was built* — source repo/commit, builder identity, and build steps — answering the question source review and output-signing can't, and directly targeting build-time tampering (the SolarWinds gap). - Provenance describes the **process, not just the result**: signing proves *who released it and that it's unaltered after signing*, provenance proves *how it was built* — you need both, because a compromised build can produce a *signed* malicious artifact but not one with *honest provenance*. - An **attestation** is a signed, machine-readable claim about an artifact (subject = artifact hash, predicate = the claim, signature = who claims it), standardized by **in-toto** — turning supply-chain trust into checkable claims (provenance, test results, SBOM) instead of faith. - **in-toto** secures the whole chain as attested steps: define expected steps, have each produce a signed attestation, and verify the chain executed as defined — catching tampering *between* steps. - **SLSA** organizes provenance/build-integrity into progressive **levels** (from "provenance exists" up to "unforgeable provenance + hermetic builds") — an incremental ladder and shared vocabulary for build assurance, letting a consumer verify an artifact was built from expected source by a trusted builder. ## Further reading - [SLSA — Supply-chain Levels for Software Artifacts (levels)](https://slsa.dev/spec/v1.0/levels) - [in-toto attestation framework](https://github.com/in-toto/attestation) --- Author: Pratik Dhanave (https://pratikdhanave.com) | Published: 2026-09-02 Canonical: https://pratikdhanave.com/blog/posts/supplychain-05-provenance-and-attestation.html Attribution: please link the canonical URL when citing or quoting this post.