If a fix exists in a newer operating system release, first check whether your release's vendor has marked the issue fixed, deferred or ignored. If it will not be fixed, choose between moving the base image to the newer release or recording a dated exception with compensating controls.
Why this happens
A distribution maintains several releases at once. A fix lands in the newest first. Whether it is backported to older releases depends on the vendor's judgment of severity, the effort and the release's support window. Ubuntu's documentation lists statuses such as fixed, fix deferred and ignored per package and release, and says ignored can mean the fix would break other functionality or the package is no longer supported. Debian similarly records per release and has stable updates for some issues.
So a scanner row that points at a newer release is telling you where the vendor fixed it, not necessarily where it will.
The decision path
- Look up the vendor status for your exact release. See Ubuntu statuses explained and Debian tracker statuses.
- If work is in progress, set a re-check date and keep the finding open.
- If deferred or ignored, assess reachability: does your service load the code?
- If it is reachable and serious, plan the base move.
- If not reachable, record an exception with an owner, reason, expiry and controls.
| Vendor status for your release | Your move |
|---|---|
| Work in progress | Wait and re-check |
| Deferred, low reachability | Exception with expiry |
| Ignored, reachable | Base move or remove the package |
| Release near support end | Base move, regardless |
What a base move involves
A move to the next release changes the C library version, package names, default shell behavior and sometimes the interpreter version. Plan for it:
- Build a pilot image and run your full test suite.
- Compare the package lists before and after. See reading an SBOM diff after a base update.
- Roll out in waves. See rolling out a patched base.
- Watch for services pinned to old library behavior.
When not to move
Skip the move if the finding is unreachable, the release has support ahead of it, and the cost of retesting is high compared with the risk. Document that choice. A dated exception is a valid answer when it names the controls and a review date.
Check the support window
If your release is close to its end of support, every future finding may be unfixable. That alone justifies planning the move. See is your base image end of life.
Where Safeguard fits
Safeguard's policies and gates can record exceptions with expiries, and its reachability analysis feeds the decision. Free scan: gold.safeguard.sh/scan.
A short example
A scan on an older base shows a High finding in a system library, with a fixed version listed for a newer release. You check the vendor page for your release and find the status is deferred, with a note that the fix is invasive. Your service does not load that library, and the container runs as a non-root user with a read just filesystem.
You record an exception: owner, the vendor note, the reachability result, the controls, and a review date three months out. At the review you check the status again. If the vendor has moved to fixed, you rebuild. If it is unchanged and your release is nearing its end of support, you schedule the base move for the following sprint.
That is a complete, defensible answer. It names the risk, the reason and the date.
Quick check
Should I jump to the newest release at once?
Move to a release that is current and supported for your timeline, and test it. The newest is not always needed.
Is an exception acceptable to auditors?
A written, dated exception with controls and an owner is a normal control. Ask your auditor about their format.
Sources
Last reviewed: 19 October 2026.
