An approved base image catalog is a short list of vetted starting images, each with an owner, a rebuild schedule and a documented purpose. Teams build from the catalog instead of pulling arbitrary public images, which limits variety and makes patching a central job.
Why keep the list short
Every extra base image is another operating system package set to patch and track. Ten teams on three images is manageable. Ten teams on forty images is not. The catalog trades a little flexibility for far less work.
Start with the images most teams already use and add only on demonstrated need.
What each catalog entry holds
| Field | Purpose |
|---|---|
| Image name and digest | Exact identity. Tags can move, digests do not |
| Purpose | Language runtime, general purpose, minimal, build stage |
| Owner | Team responsible for rebuilds and fixes |
| Source and build recipe | How it is made, kept in source control |
| Rebuild schedule | For example, rebuilt on a fixed cadence and on high severity fixes |
| Scan result | Latest findings and date |
| Support window | When the entry will be retired |
| SBOM | List of packages inside |
Publishing and using it
- Build catalog images in a controlled pipeline from a recipe in version control.
- Scan after each build and block publishing if findings exceed policy.
- Publish to the internal registry under a protected path that only the pipeline can write to.
- Require application Dockerfiles to start from a catalog path, and check this in CI.
- Reference by digest in production manifests, and let an update tool propose digest bumps.
Keeping it patched
The advantage of the catalog is central rebuilds. When a base layer fix lands, rebuild the catalog image once, then application teams rebuild on top. Track how long it takes for application images to pick up a new base. That lag is your real exposure, not the catalog's own freshness.
When teams need something else
Provide a request route. Some workloads need a special runtime or tool. Allow an exception with an owner and review date, and add the image to the catalog if several teams ask for it.
Retiring entries
Mark an entry deprecated with a date, notify users from the registry log or SBOMs, and block new builds on it at the stop date. Follow the same steps as retiring any approved package.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how findings split between the base image and your own layers.
Quick check
Tag or digest in the Dockerfile?
Use the digest for repeatability, and automate updates so it does not go stale.
How many images should the catalog have?
As few as your workloads allow. Add one only when several teams need it.
Safeguard scans dependencies and builds SBOMs, runs reachability analysis, and applies policies and gates on pull requests, so the rules in this post can be checked automatically. Autonomous fix PRs are off by default, with every category on Manual. You can run a free scan at gold.safeguard.sh/scan.
Last reviewed: 19 October 2026.
