How do you make an approved-base-image rule match when each tool names the image differently?

## Three names for one image The same container image legitimately appears in your evidence under at least three forms: - a **tag** — a registry host, a repository path and a human label, resolved to an image by the registry at the moment of use; - a **digest** — a content hash over the image manifest, which names exactly one set of bytes; - a **package URL string** — a structured identifier carrying the name and a version or digest plus qualifiers such as the repository, produced by inventory and SBOM tooling. They are all correct. They are not comparable. A rule that string-compares whatever field it happens to find will either match nothing or match by accident. ## Why the digest is the join key A tag is a pointer, and pointers move. An approval recorded against a tag is an approval of whatever that tag names today, which silently transfers to every image published under it afterwards — the review happened on bytes that may no longer be there. A digest is derived from content, so an approval recorded against a digest means exactly what it meant when it was granted. Key the inventory on digests; keep tags as human-facing aliases, ideally with the window in which each tag pointed at each digest. This is a question about how the *join* is keyed. Whether deployments must themselves reference images immutably is a separate rule with a separate owner. ## Resolve at production time, not at gate time The tempting shortcut is to let the gate resolve the tag when it evaluates. That answers *what does this tag mean now*, which is not the question. Between the scan and the gate the tag can be moved, so you would be comparing a freshly resolved digest against a report describing a different image, and the comparison would succeed. Resolve once, at the moment the evidence is produced, by the component that knows the answer with certainty: the pipeline knows the digest it pushed, the runtime knows the digest it pulled. Carry that digest through every downstream record. ## Two traps that look like bugs and are not **Default host and namespace expansion.** The same image can be written with or without a default registry host and a default namespace. Two spellings, one image, and byte-for-byte they differ. Whatever canonical form you choose, apply it in the normaliser, not in each rule. **An index digest is not a manifest digest.** A multi-platform image is published as an index that references one manifest per platform, each with its own digest. A tool that scanned the index records the index digest; a node that pulled the linux/amd64 variant records that manifest's digest. Both records are accurate and they will never compare equal. Decide which one your inventory is keyed on, normalise to it consistently, or store both and match on either. ## Base image versus the artifact under test The artifact being admitted is your built image; the thing the rule cares about is what it was built *from*. That relationship is not recoverable from the artifact's own name — it comes from build metadata or an inventory record that captured it at build time. A rule that infers a base image from a tag naming convention is reading a comment, not a fact. ## What happens when the key is missing This is the failure worth rehearsing, because it is silent. If the rule keys on a digest field and half your reports carry only tags, then for those artifacts the comparison has nothing to work with: the rule produces no result, no denial is emitted, and the artifact is admitted unexamined. The gate looks like it is running and blocking nothing because everything is compliant. The defence is the same discipline as any other missing evidence — assert that the identity resolved before comparing it, and route unresolvable identity to unknown with a message naming the reference that could not be resolved. The opposite failure is worse: a normaliser that helpfully fills a missing digest by resolving the tag itself. Now the record is confident, wrong, and indistinguishable from a good one. ## What the inventory should hold Keyed by digest. Tags recorded as aliases with the period they were valid. Enough provenance that a human can see which image was reviewed. And a clear answer to what happens to a workload already running an image whose approval was later withdrawn — because that is a different decision from admitting a new one, and the inventory record is what makes it answerable.