Your Kyverno verifyImages rule gates scan freshness — what can it prove to an auditor about workloads already running?

## The claim the auditor wants, and the claim you have The auditor's question is about the present tense: *is everything running right now covered?* An admission-time rule answers a different question, in the past tense and per event: *was this object, at the moment it was created, accompanied by evidence that satisfied the condition?* The gap between those two sentences is the entire substance of this problem, and a candidate who states it crisply has already answered most of the question. ## Three specific gaps **1. Workloads that predate the policy.** Admission control evaluates requests. A pod created before the rule existed generated no request afterwards, so it was never evaluated and it is still running. In a cluster with long-lived workloads this is not a small population — a stateful service that has not been redeployed in five months sits entirely outside your evidence. **2. Decay after admission.** A freshness condition is evaluated once. A pod admitted six weeks ago with a two-day-old attestation satisfied a fourteen-day rule at the time; today the same attestation is forty-four days old, and nothing revisits it. The control is genuinely real, but what it enforces is *freshness at deploy time*, and the fleet's actual freshness is a function of how often you deploy. That reframing is the useful one: the true control is "scan freshness at admission" combined with "maximum time between deployments", and only the first half lives in the policy. **3. Images outside the selector.** A rule only evaluates images its `imageReferences` patterns select. Anything outside them was admitted without ever being considered, and produced no failure to notice. Coverage is therefore its own evidence question, separate from pass rates. ## What actually closes each gap - **Re-admission on a schedule.** If workloads are recreated regularly — a periodic rollout, or a policy that nothing runs longer than N days without redeployment — then every pod has been through the gate recently, and "admitted within the last N days" plus "the gate enforces a fourteen-day window" composes into a bound on fleet staleness. This is the honest way to turn a point-in-time gate into a continuous property, and it is an operational commitment, not a policy edit. - **An out-of-band check of what is running.** Enumerate the images actually in use across the cluster and evaluate the same condition against their attestations on a schedule, independently of admission. This directly answers the present-tense question, catches the pods that predate the policy, and is the only thing that detects decay. - **Coverage evidence.** Show that every running image reference matches a rule, typically by keeping a catch-all rule so that "selected by nothing" cannot happen. ## The organisational judgment The temptation, under audit pressure, is to let the auditor believe the gate proves more than it does. It is a bad trade in both directions: it fails the first time somebody looks closely, and internally it stops anyone from funding the periodic check that would make the claim true. The better move is to describe the control in the terms it actually operates in — "images are verified at deployment; workloads are redeployed at least every N days; a scheduled check evaluates what is running against the same condition and raises exceptions" — and to be explicit about the residual: the population admitted before the rule, and the window between checks. Auditors are generally comfortable with a control described accurately with a stated residual risk; they are much less comfortable discovering the residual themselves. That framing also settles internal arguments that would otherwise recur, because it names who owns which half. The platform team owns the gate. Whoever owns deployment cadence owns the decay half, and if a team wants an exception from periodic redeployment, they are asking for an exception from the control, which is a conversation with an owner rather than a policy-file edit. ## What not to claim Be precise about the evidence trail too. The decision record shows requests that were allowed or refused; it is a log of gate outcomes, not an inventory of what is running. Anyone building a compliance dashboard directly from admission outcomes is building a picture of *deployment activity*, and it will look complete while omitting exactly the workloads that have not been touched in months — which are the ones most likely to be stale.