How do artifact signing and provenance protect the software supply chain?

Supply-chain attacks work by getting you to run something you trust but shouldn't — a tampered binary, a malicious build, a swapped dependency. Signing and provenance let you verify trust instead of assuming it.

Signing: who made this?

Artifact signing produces a cryptographic signature over an artifact (a container image, a package, a binary). A consumer verifies the signature to confirm two things: the artifact came from the expected producer, and it hasn't been altered since signing. Traditional signing struggles with key management — long-lived private keys get lost or stolen. Sigstore addresses this with keyless signing: it uses short-lived certificates tied to an OIDC identity (e.g. a CI workflow's identity) and records signatures in a public transparency log (Rekor), so there's no long-term key to protect and every signature is auditable.

Provenance: how was this made?

A signature alone doesn't tell you how an artifact was built. Provenance is signed, tamper-evident metadata that attests to the build: which source commit, which builder, which inputs and parameters. The SLSA framework defines escalating levels of provenance and build integrity, so you can say "this artifact has verifiable provenance from a hardened, non-falsifiable build pipeline."

Putting it to work

The two combine at deploy/admission time: a policy verifies the image is signed by the expected identity and carries provenance pointing to the expected source repo and builder. An attacker who swaps in a malicious image can't forge that, so deployment is blocked. This is what defeats incidents like a poisoned build artifact slipping into production.

What interviewers look for

They want signing (integrity + identity) and provenance (build origin) clearly separated, awareness of Sigstore's keyless model and SLSA levels, and the verify-at-admission enforcement point.