Artifact Integrity, SLSA and Provenance

There is a gap in most software supply chains that hides in plain sight. Teams review their source code and trust their build system, then deploy an artifact — a container image, a binary, a package — and simply assume it is the thing the pipeline produced. But between build and deploy, and between deploy and every downstream consumer, that artifact passes through registries and hands. If an attacker can substitute or tamper with it in transit, every control upstream is irrelevant. Provenance is how you close that gap: proof of what was built, from what, by whom.

The question provenance answers is deceptively basic: is this artifact the one my trusted process created, unchanged? Without an answer, you are trusting the artifact because it arrived in the expected place with the expected name — which is exactly the assumption a registry compromise or a tampered mirror exploits. High-profile supply-chain attacks work precisely by inserting malicious code into a trusted, widely-distributed artifact, so that thousands of downstream consumers install it believing it came from the legitimate source. Provenance is the countermeasure that lets the consumer verify rather than assume.

Signing proves who; provenance proves how

Two related mechanisms do the work. Signing attaches a cryptographic signature to an artifact so a consumer can verify it was produced by a specific, trusted key and has not been altered since. Provenance goes further: it is signed metadata describing how the artifact was built — which source commit, which builder, which parameters — so you can verify not just that it is unchanged, but that it came from your pipeline building your code, not an attacker's build of something else. Signing answers 'who vouched for this'; provenance answers 'how was this actually made'.

SLSA as a ladder, not a checkbox

SLSA (Supply-chain Levels for Software Artifacts) is a framework that describes increasing levels of build integrity — from simply generating provenance, up to builds that run in hardened, isolated environments producing non-forgeable provenance. Its value is as a maturity ladder: it names the concrete steps between 'we build somewhere' and 'we can cryptographically prove exactly how every artifact was produced'. You do not need the top rung to benefit; each level closes a specific class of tampering, and generating provenance at all is a large step up from nothing.

• Sign every artifact you produce. Container images, binaries and packages should carry a signature tied to a key your consumers can trust.
• Generate provenance in the build. Emit signed metadata linking each artifact to its source commit and build parameters — the record that lets anyone reconstruct and verify its origin.
• Enforce verification at deploy. The admission control that refuses unsigned or unverifiable artifacts is where signing becomes a defence rather than a formality.
• Pin what you build from. Provenance is only as trustworthy as the inputs; reproducible builds from pinned sources make the metadata meaningful.
• Protect the signing keys. A signing key is a trust anchor; in an HSM or a keyless signing service, never sitting in a build variable.

The failure is always the unchecked path

The recurring mistake is asymmetric adoption: a team invests in signing and provenance on the build side, then deploys through a path that never verifies. An attacker simply uses the unverified path. Provenance is a two-sided contract — producing the evidence is worthless unless something downstream demands and checks it. Close the loop, and a substituted or tampered artifact fails to deploy instead of silently shipping.

You cannot sign, attest or verify artifacts from build paths you do not know exist — and the un-inventoried pipeline is the one shipping unverified images. Artifact integrity, like the rest, begins with discovering every path that produces what you deploy.