Signing and Provenance¶

Immutability guarantees a tag can't be silently repointed — but it doesn't tell a consumer who published an artifact or how it was built. That's a separate question, answered by signing and provenance, at the concept level a DevOps junior needs.

TL;DR — in 30 seconds:

Signing (e.g. with cosign) attaches a cryptographic signature to an artifact, so a consumer can verify it hasn't been tampered with since it was signed, and by whom (or by which pipeline identity).
Provenance (the idea SLSA formalizes) is a separate attestation describing how an artifact was built — from what source repo, what commit, by which build system — not just that it's signed.
Signing answers "has this been tampered with, and by whom was it signed?"; provenance answers "was this actually built by the pipeline I expect, from the source I expect?" — a consumer may want both.

1. Signing¶

Cosign (part of the Sigstore project) signs a container image (or other OCI artifact) and stores the signature alongside it in the registry. A consumer verifies the signature before using the image, which proves two things: the image's content hasn't changed since it was signed, and it was signed by a specific, verifiable identity.

Cosign supports keyless signing: instead of managing a long-lived private signing key, the signer authenticates with an OIDC identity (e.g. "this GitHub Actions workflow, in this repo"), and Sigstore's transparency log records that the signature happened, tied to that identity, without either side needing to manage key material long-term.

flowchart LR
    A["CI builds<br/>the artifact"] --> B["Sign it<br/>(cosign)"]
    B --> C["Push signed artifact<br/>to registry"]
    C --> D["Consumer verifies<br/>signature before use"]
    D -->|"valid"| E["Deploy"]
    D -->|"invalid / missing"| F["Reject"]

2. Provenance and SLSA¶

Signing proves an artifact hasn't been altered since signing — it says nothing about how it was produced in the first place. Provenance closes that gap: a structured, attached record of the build — which source repository and commit it came from, which build system ran it, and what steps it took — so a consumer can verify the artifact actually came from the expected pipeline, not just that someone signed it.

SLSA (Supply-chain Levels for Software Artifacts) is the framework that formalizes this: it defines a set of graduated levels of build integrity — the higher the level, the stronger the guarantee that the provenance record can be trusted (e.g. that the build ran in an environment the pipeline author couldn't tamper with after the fact). A junior doesn't need to memorize the exact level criteria — the concept to take away is: provenance is a verifiable claim about the build process itself, and frameworks like SLSA exist to make that claim trustworthy rather than self-reported.

flowchart LR
    A["Source repo<br/>+ commit"] --> B["Build system<br/>runs the build"]
    B --> C["Build steps<br/>recorded"]
    C --> D["Provenance<br/>attestation attached"]
    D --> E["Consumer verifies<br/>expected source & pipeline"]

3. Why both matter, and what neither one is¶

Question	Answered by
Has this artifact been altered since it was published?	Signing
Who (or which pipeline identity) signed it?	Signing
What source commit and build system actually produced it?	Provenance (SLSA)
Is the artifact free of vulnerabilities?	Neither — that's a separate concern (image scanning)

Signing and provenance both answer trust questions about the artifact's origin and integrity — neither one is a substitute for vulnerability scanning, which is a different check entirely.

Common gotchas

Treating "it's signed" as proof it's safe to run. Fix: signing proves origin and integrity, not the absence of vulnerabilities — pair it with image scanning, don't substitute for it.
Assuming provenance is the same thing as a signature. Fix: a signature verifies the artifact hasn't changed and names who signed it; provenance separately verifies how it was built — a consumer can want either, or both, depending on the guarantee needed.
Trying to memorize SLSA's exact level criteria before understanding the concept. Fix: get the idea first — provenance is a verifiable build record, and SLSA grades how hard that record is to forge — then look up the specific level requirements only when a real policy requires targeting one.

Check yourself — an artifact is validly signed by the expected pipeline's identity. Does that tell you it was built from the source code you expect, on the branch you expect?

Not by itself. A valid signature confirms the artifact hasn't been altered since signing and names who signed it — it doesn't say what source commit or build steps produced it. That's what a provenance attestation (the kind SLSA formalizes) is for; verifying both together gives you integrity and origin.

Done when: you can state, in one sentence each, what signing verifies and what provenance verifies, and name one thing neither of them checks.