Your pipeline signs every container image but nothing verifies the signature — what does that buy you?
answer
- evidence versus enforcement
- a claim nobody reads
- the refusal is the control
- something must fail closed
- gate, admission, or pull time
basics
~20 sAlmost nothing on its own. A signature is only a claim until something refuses an artifact whose signature is missing or wrong. The value appears at the enforcement point: a pipeline gate, admission, or pull-time policy.
solid answer
~40 sBy itself, very little. Signing produces a verifiable claim — this artifact, from this identity — bound to the image digest, but a claim nobody reads changes no behaviour: an attacker who swaps an image is stopped only by something that refuses the swap. The security event is the refusal, so the real question is where the refusal lives. There are three seats: a gate in the delivery pipeline before promotion, an admission check when a workload tries to start, and a policy in the container runtime at pull time. Each sees a different slice of what actually runs. Signing first is still correct — it is a cheap prerequisite — but treat the work as unfinished until at least one choke point fails closed on a bad or missing signature.
go deeper
Be ready to say plainly that a signature is only a claim, and that some system has to check it and refuse before anything is protected. Know that the check can live in the pipeline, at admission, or at image pull.
Explain the split between producing evidence and consuming it, and why the consuming side is the harder half — it sits in someone's path and can block real work. Be able to distinguish a detective report from an enforcing refusal.
Expect to be asked which seat you would turn on first in a specific estate and what would break. Show that you would inventory what currently fails before making any check mandatory.
Own the argument for why the evidence-producing half spreads easily and the enforcing half stalls, and how you fund and staff the second half rather than declaring victory on the first.
## What a signature is, and what it is not Signing an artifact produces a detached, cryptographically verifiable statement: *some identity vouches for the content with this digest*. It says **who vouches for it**. It does not say what is inside the artifact (that is an SBOM's job) and it does not say how the artifact was produced (that is provenance's job). And crucially, producing that statement changes nothing about what any machine will run. A signature is evidence, and evidence only matters when someone checks it. This is the single most common gap in real estates. A team turns on signing in the build pipeline, sees signatures appear next to every image in the registry, and reports the control as done. Nothing in the path from registry to running process ever looks at them. An attacker who pushes a mutated image under a tag your deployment references, or who convinces a deployment to point somewhere else, is not inconvenienced in the slightest — nothing on that path is reading the evidence. ## The control is the refusal So the useful mental model is: signing produces the evidence, and a separate thing — an **enforcement point**, or choke point — consumes it and refuses. The refusal is the control. Everything else is preparation. There are three places that refusal can live, and they are genuinely different controls: | Seat | When it runs | What it can refuse | |---|---|---| | Pipeline gate | Before an artifact is promoted or a deployment is applied | The promotion or the deploy action | | Admission | When a workload is created in the orchestrator | The workload object, before anything schedules | | Pull-time runtime policy | When the host fetches the image | The image pull on that host | A fourth thing that looks like enforcement but is not: a **report**. A dashboard listing which running images have no valid signature is a detective control — useful, but it does not stop anything. If your answer to *where is verification enforced* is a weekly report, verification is not enforced. ## Why signing first is still the right order None of this means signing is wasted. You cannot verify what was never signed, so signing is the strictly earlier step, and it is the cheap half: it happens once, in a build system you already own, and it does not sit in anybody's availability path. Enforcement is the expensive half, because a check that refuses things is a thing that can refuse the wrong thing at the wrong moment. That asymmetry is exactly why so many estates stop after the cheap half. Recognising that state — signatures everywhere, no verifier anywhere — and being able to say what it is worth is a normal interview screen in this area. ## Related failure modes worth knowing - **Verification exists but is advisory.** A check that logs a warning and lets the deploy through is the same as no check, with extra logs. - **Verification runs somewhere nothing bypasses is the whole point.** If the check lives in a pipeline anyone can edit or skip, the party being constrained controls the constraint. - **A tag is not content.** A signature covers a digest. If verification resolves a mutable tag and checks whatever it resolves to right now, you have verified something, but not necessarily the thing that will run later. - **Signing the wrong subject.** Signing a release archive while deploying an image built from it means the deployed thing carries no covered claim at all. ## What good looks like At minimum: builds sign, the registry stores the signatures, and at least one seat between the registry and a running process fails closed when the signature is missing, malformed, or made by an identity that is not on the accepted list. Which seat you choose is a real design decision with real coverage and availability trade-offs — but choosing none of them is not a design, it is an unfinished rollout.
- Name the places that refusal could live, and say which one sees the most of what actually runs.Three: a gate in the delivery pipeline before promotion or deploy, an admission check when a workload is created in the orchestrator, and a pull-time policy in the container runtime on the host. Admission sees the most of what actually starts, because it evaluates everything that reaches the orchestrator regardless of which pipeline, chart, operator or human created it. The pipeline gate only ever sees artifacts that flowed through that pipeline.
- A dashboard flags running workloads whose images have no valid signature. Is that enforcement?No, it is detection. It tells you the bad thing is already running, which is valuable for inventory and for finding the gaps in your enforcement coverage, but nothing was refused. Detection and enforcement answer different questions: detection tells you what got through, enforcement determines what gets through. If the dashboard is your only control, an attacker's image runs until a human reads a list.
- If the check has to go in somewhere first, and signing is already done, what do you need before you can turn one on?An honest inventory of what is running and who signed it, and a decision about which identities are acceptable. Turning on refusal without knowing what currently fails means finding out in production. You also need the verification material — trust roots and any accepted-identity list — reachable and current at the seat you chose, because that becomes a live dependency the moment the check is mandatory.
A signed visitor badge printed at reception protects nothing if no door ever checks it. The badge is evidence; the locked door is the control.
saying these in an interview costs you the question
- Claims signing alone makes the supply chain tamper-proof
- Assumes registries verify signatures on push automatically
- Cannot name a single place where a check could refuse
- Treats a report of unsigned images as enforcement
- Says a warning-only check counts as verification