If a service must stay on an unsupported base image for now, write a time boxed exception: a named owner, the reason, controls that limit exposure, a review date and a firm end date. An exception with those parts is a managed risk. Without them it is a leftover that grows quietly.
Why exceptions are sometimes honest
Migrations stall for real reasons. A vendor library supports only the old release. A certified build cannot change until a validation cycle ends. A team is down to one engineer. Pretending these do not exist produces silent non compliance. Writing them down produces a plan.
The aim is to keep the list short, visible and shrinking.
What an exception record contains
| Field | Example content |
|---|---|
| Image and service | Name, registry path, running digest |
| Base and its support status | Release name and the publisher's end date, with the source link |
| Reason | The specific blocker, in one or two sentences |
| Owner and approver | Named people, not teams alone |
| Compensating controls | What reduces exposure while it stays |
| Review date | When someone re-checks the exception |
| End date | When it expires unless renewed with justification |
| Exit plan | The steps and the person who will do them |
Keep the form short enough that people fill it in.
Compensating controls that make sense for a container
Choose what fits the service. None of these is a substitute for moving, but each limits what an attacker can do.
- Reduce network exposure. Remove public access, or put the service behind an authenticated front end.
- Limit what the container can do. Run as a non root user, drop capabilities and use a read only root filesystem where the app allows it.
- Remove what you do not need. Strip build tools and unused packages so there is less to exploit.
- Watch it. Keep the image in scheduled scans so a new finding reaches the owner quickly.
- Rebuild anyway. Even an unsupported base may accept fixes from other sources you add, and a fresh rebuild keeps your own layers current.
Setting the end date
Pick a date tied to something real, such as the end of a validation cycle or a vendor release, not an arbitrary far off one. Renewals should require a fresh written justification and a more senior approver each time. That friction is intentional.
Reporting
Report the count of open exceptions and their age to leadership each quarter. A rising count is a signal about capacity, not only security. Showing a falling count is one of the more convincing things you can tell a customer or auditor about your process.
Check the support date again
Publishers' dates change and extended arrangements exist. Debian, for example, lists a Long Term Support period after regular support, run by a separate group of volunteers and companies. Read the publisher's current page before you declare something unsupported or supported, and keep the source link in the record.
Where Safeguard fits
Safeguard keeps exception style decisions with expiry in its policies, and continuous monitoring keeps scanning images that sit on an exception so a new finding does not wait for the next review. The free scan at https://gold.safeguard.sh/scan covers one image.
Quick check
How long should an exception last?
Only as long as the blocker does, and usually no more than a quarter or two before review. Renewals should be harder than the first grant.
Who should approve one?
Someone who owns the risk, such as the service owner's director or security lead, not only the engineer who asked.
Sources
Last reviewed: 19 October 2026.
