Build the same application on both candidate bases, generate an SBOM and a scan for each, run your startup test, check the publisher's support date, and score the results in a table. A trial with your own app beats any general advice because it measures the things that affect you.
Step by step
- Fix the application. Use one real service with its real dependencies, not a hello world.
- Build it on each candidate with the same Dockerfile structure. Change only the FROM line and what must change to make it work.
- Generate an SBOM for each result with the same tool and scope.
- Scan each image with the same scanner, on the same day.
- Run the startup and smoke tests, and note anything that needed a workaround.
- Look up each base's support end date on the publisher's page.
Doing everything on the same day matters, because scan results shift as advisories arrive.
What to measure
| Measure | Why it matters | Caution |
|---|---|---|
| Package count in the SBOM | Fewer packages means less to patch | Count alone is not risk |
| Findings by severity | A starting picture of exposure | Many are not reachable |
| Findings with a fix available | Shows how patchable the base is | Depends on the scan date |
| Image size | Pull time and storage | Not a security measure by itself |
| Build and test effort | Real cost of adoption | Often the biggest factor |
| Support end date | How long before you must migrate | Read the publisher's page |
| Debug story | Can your team troubleshoot it | Minimal images lack shells |
Docker's guidance recommends a minimal base that matches your requirements, and notes that a smaller base offers portability, faster downloads and a smaller attack surface. The trial tests whether that holds for you.
Reading the findings fairly
Do not compare raw totals. Separate operating system findings from application library findings, since only the first depends on the base. Check which findings have a fix available and which would be fixed by a rebuild. A base with more findings that all have fixes may be better managed than one with fewer and none.
Reachability matters too. A finding in a package your service never loads is lower priority than one in a path you call. Treat counts as a prompt to look, not a score.
Check the non security costs
Test the things that break on a base change: native extensions, locale and timezone data, certificate handling, and the debug tools your on call team relies on. A base that scores well on security and cannot be debugged at three in the morning will lose in practice.
Write down the decision
Record the candidates, the date, the numbers, the support dates and the reason for the choice. When the question returns in a year, you will have the answer. Add the winner to your approved list with a review date.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how findings split between operating system packages and application libraries.
Where Safeguard fits
Safeguard's container image scan and SBOM give you the same measurements for both candidates with a consistent method, and reachability analysis helps separate findings you call from findings you never load. The free scan at https://gold.safeguard.sh/scan is an easy way to run the first one.
Quick check
Is the image with fewer findings the better base?
Not on its own. Compare findings that have a fix, findings that are reachable, support dates and how well it runs your app.
How many candidates should I trial?
Two or three is plenty. More than that mostly produces a spreadsheet.
Sources
Last reviewed: 19 October 2026.
