An auditor asks what your approved-base-image gate actually establishes — what controls do you name beside it?

## The question behind the question When an auditor asks what a control establishes, they are not trying to catch you out; they are trying to write down a true sentence. The failure mode is answering "we enforce approved base images," which sounds like a guarantee and is not one. The productive answer names the gate's exact claim and then names what sits beside it to cover the rest. ## What the gate owns The base-image gate is **preventive** — it acts before the artifact is used — and it is **mechanical**: it compares a recorded field against a published set. Its strengths are exactly the strengths of automation: it runs on every single build with no sampling, applies the same standard regardless of who submitted the change or what time it is, and produces a decision record without anyone remembering to write one. Its claim is narrow and precise: *this image's recorded base was, or was not, on the approved list at build time.* ## What sits beside it, and what each covers **Human review (code or design review).** This is the control that owns **necessity and intent**. A reviewer can ask the requester why a vendor's base image is required, whether the driver really only ships for that distribution, whether the migration that justified it has an end date, and whether a smaller change would avoid it. None of that is expressible as a predicate over the image, because none of it is in the image. Review is expensive, inconsistent between reviewers, and does not scale linearly — which is precisely why you want the mechanical part automated and the review reserved for the judgement. **Runtime detection.** This is a **detective** control: it observes the workload after it starts and reports on what it does. It covers a different failure entirely — the image that used a perfectly approved base and then installed something unwanted three layers later, or behaves badly only under real traffic. A build-time predicate over base metadata can never see this, because at build time the behaviour has not happened yet. **Tests and other build-time checks.** Automated tests and content scanning cover properties of the artifact other than the base identity. They share the gate's shape (mechanical, preventive, uniform) but a different subject. **Ownership of the approved list.** Someone has to periodically ask whether the entries are still appropriate. The gate faithfully enforces a list it never questions; a stale list produces green builds indefinitely. ## Saying it in one paragraph > "Every image build is checked against a published set of approved base images; that check is automatic, applies to all builds, and its result is recorded. It establishes which base was recorded, not whether a deviation was warranted. Deviations go to a named reviewer who judges necessity with the requester. Separately, running workloads are monitored, which covers behaviour that no build-time check can see." That paragraph survives a follow-up question. "We enforce approved base images" does not. ## The pairing discipline The useful habit is to write, for each rule you own, one line naming what it asserts and one line naming who covers the rest. If the second line is blank, you have found a real gap: a judgement nobody is making, or a class of failure nobody is watching for. If the second line says "a stricter version of the same rule," you have not found a compensating control — you have found more of the same control, and it will hit the same wall for the same reason. A compensating control is only compensating if it works on a **different input**. Review works on a conversation with a person; runtime detection works on observed behaviour; the gate works on a recorded field. Three inputs, three classes of decision. Two rules over the same document are one control with more clauses.