A base image register is a single list of every image your organisation builds or runs, with enough fields to answer three questions fast: what is this based on, who owns it, and when does its support end. About ten fields cover it, and most can be filled automatically from your build and scan data.
The fields
| Field | Why it earns its place |
|---|---|
| Image name and registry path | Identifies the artifact |
| Owner (team and contact) | Someone must act when a base ages out |
| Base image name | The family you chose, such as a Debian slim variant |
| Base image digest | The exact content you built on |
| Operating system release | Needed to look up the end of support date |
| Support end date and source URL | Drives the migration calendar |
| Last rebuild date | Shows whether fixes can have arrived |
| Where it runs | Production, staging, internal, customer delivered |
| SBOM location | The package level record for this build |
| Exception, with end date | Explains anything that is out of policy |
Resist adding more until these are reliable. A register with forty empty columns is not read.
Where each field comes from
Most of it exists already. The base name and digest are in the Dockerfile and build logs. The OCI image specification defines annotations for this, including org.opencontainers.image.base.name and org.opencontainers.image.base.digest, so you can stamp them at build time and read them later. The operating system release and the package list come from an image SBOM or scan. The rebuild date comes from the registry. Owners come from your repository metadata or service catalogue.
How to start without a project
- Pull the list of image references from your cluster and your registry.
- Group by base image. A pivot of "how many images share each base" often shows you five bases cover most of the estate.
- Fill in support dates for those few bases from the publisher pages.
- Find owners for any image with no obvious one. Unowned images are the main finding of the first pass.
- Decide who updates the register after that. Automatic is ideal, and a named person is the fallback.
How the register gets used
Three recurring uses justify the effort. During a base image advisory, you filter by base and get the affected list in minutes. During planning, you sort by support end date and size the next migration wave. During an audit or a customer review, you show the register and the SBOM links as evidence that you know what you run.
Keeping it honest
Add a review date to the register itself. If nobody has touched it in a quarter, treat the contents as suspect. Stale registers are worse than none because they give false confidence.
Where Safeguard fits
Safeguard's asset discovery and per image SBOMs supply most of these fields without manual entry, and compliance evidence can point back to the same records. The free scan at https://gold.safeguard.sh/scan shows what a single image record looks like.
Try it yourself
Click through it at your own pace, or open it full screen. Open an inventory and look at which fields are recorded for each component, then picture the same for each image.
Quick check
Should the register list every tag or every digest?
List what runs. Tags move, so record the digest that is deployed, and keep the tag as a human friendly label next to it.
Who should own the register?
A platform or security engineering team usually owns the process, but each image has a named owning team who keeps its own row correct.
Sources
Last reviewed: 19 October 2026.
