A build-time policy check verifies a container image's base image is on the approved list — what can it not establish?
answer
- A predicate reads facts, not reasons
- The field records which, never why
- Necessity is not in the artifact
- Approved base covers one layer only
basics
~20 sIt establishes one fact: the recorded base image matches a list. It cannot establish whether an unapproved base was justified, whether the approved one was the right choice, or whether anything layered on top of it is safe.
solid answer
~50 sThe check is a predicate over a document. It reads one field — the base image the build recorded in the image's metadata — and answers whether that string or digest is in a published set. That answer is exact and cheap, and it is the whole of what the control asserts. It says nothing about *why* this base was chosen, whether a team that used an unapproved one had a real reason (a vendor appliance, a driver that only ships for one distribution, a migration still in flight), whether the approved list is still the right list, or what the fifteen layers added on top of the base contain. It is also self-reported by the build, so it records what the build claimed rather than proving it. Those are the things a human reviewer is for, and knowing the boundary is what keeps you from over-claiming when someone asks what the gate proves.
code
json · 8 lines{
"annotations": {
"org.opencontainers.image.base.name": "internal.example/base/python:3.12-slim",
"org.opencontainers.image.base.digest": "sha256:9f2c...",
"org.opencontainers.image.revision": "4c1e9ab",
"com.example.team": "payments"
}
}go deeper
Be ready to state plainly what the check reads (one recorded field) and what it decides (membership in a list), and to name one thing it cannot see, such as why an unapproved base was chosen.
You should be able to walk through where the base reference comes from, that it is written by the build, and why intent and necessity are absent from the document rather than merely hard to extract.
Expect to be pushed on how you describe the control to other people — the difference between "deviations are visible and reviewed" and "we control base images" is the sentence that gets audited.
Own the framing that a guardrail's value is bounded by what its input document contains, and that expanding coverage means changing what gets recorded, not writing a cleverer rule.
## What the check actually asserts A policy check on container base images is a predicate over a document. The build records which base image it started from — typically as an annotation or label on the image, alongside the digest — and the rule compares that value against a published set of approved base images. It returns yes or no. That is a complete answer to exactly one question: *is the recorded base reference in the approved set?* It is a very good control for that question. It runs on every build, costs milliseconds, never gets tired at 6pm, applies the same standard to the most senior engineer and the newest hire, and leaves an unambiguous record of what it decided. None of that is diminished by the list below — the point is only that a fact is not a judgement. Everything a reviewer actually cares about sits one level above that field. ## The three things the predicate cannot reach **Intent — why this base.** The metadata records *which* base, never *why*. Two images with the same unapproved base can be a careless copy-paste from a blog post and a deliberate choice forced by a hardware vendor's driver package. The document is byte-identical in the field the rule reads. No amount of care in writing the rule recovers a reason that was never written into the artifact. **Necessity — whether a deviation was required.** "Was this justified?" is not a property of the image; it is a property of the situation the image was built for. A vendor appliance shipped as a fixed image, a one-off migration container that has to match a legacy runtime, a research workload that needs a GPU vendor's base — each of these is a legitimate deviation whose legitimacy lives entirely outside the file. The rule can see the deviation. It cannot see the necessity. **Scope — what the approval covers.** An approved base says something about the first layer. It says nothing about the packages installed on top, the credentials baked into an environment variable, the entrypoint that curls a script at start-up, or the application code. "Approved base" is a common shorthand for "this image is fine," and that shorthand is wrong. Nor does the check validate the list itself: if an image sat on the approved list for eighteen months without anyone re-examining it, every build passes while inheriting the same stale content. There is a fourth, quieter limit: the base reference is asserted by the build that produced the image. The check reads what the build said, which is a different claim from proving what the build did. ## Fact versus judgement, side by side | Question | Decidable from the artifact? | Who can answer it | |---|---|---| | Is the base on the approved list? | Yes | The rule | | Was an unapproved base necessary here? | No | A human reviewer with context | | Should this base still be approved? | No | Whoever owns the list | | Is the rest of the image safe? | Partly, by other checks | Other controls | ## Why this matters on day one The common junior mistake is not writing a bad rule; it is describing a good rule too generously. When someone asks "do we control our base images?", the honest answer is "every build is checked against an approved list, and deviations are visible — whether a deviation was reasonable is decided by a person." That sentence is defensible. "Yes, we control base images" invites a follow-up you cannot answer. The practical consequence is that this rule is best treated as a filter that surfaces a small set of cases for someone to look at, not as a machine that has finished the job. The predicate does the part that is mechanical and uniform; a review does the part that requires knowing why.
- If two teams both use an unapproved base, one carelessly and one because a vendor driver requires it, what does the gate see?Exactly the same thing: a base reference that is not in the approved set. The field the rule reads is identical in both images, so the gate produces the identical decision. Distinguishing the careless case from the forced one needs information that was never written into the artifact — which is why the useful output of the rule is often "someone should look at this one" rather than a verdict.
- An image passes the approved-base check and later turns out to ship a vulnerable library. Did the control fail?No — it was never asked that question. The check asserts one property of the first layer; the library arrived in a layer added afterwards. Treating a pass as a general statement about the image's safety is the mistake, not the rule. Contents added on top are the job of other checks, and describing the gate accurately is what keeps people from assuming coverage that does not exist.
A passport scanner can confirm the document is genuine and the name matches the list. It cannot tell you whether this person had a good reason to be on the flight.
saying these in an interview costs you the question
- Saying a passing base-image check means the image is safe
- Claiming the rule proves the deviation was unjustified
- Assuming approval of a base covers everything layered on it
- Believing a better-written rule could infer intent
- Treating the self-reported base label as proof of what was built