Write the exception around the image, not just the CVE: name the exact image digest and package, explain why exposure is limited, state what you are watching for the upstream fix, and set an expiry short enough that you will actually look again. A "no fix available" status is a reason to track, not to forget.
Container scans routinely report OS package findings that the distribution has not patched yet. You cannot upgrade your way out, so the record has to carry the reasoning.
Step 1: Verify there really is no fix
Check three places: the distribution's security tracker for that release, a newer tag of the same base, and a different base that does ship the fix. If a newer image or alternate base fixes it, an upgrade plan beats an exception. If the distribution marks it as will not fix or minor, record that status with the date you checked.
Step 2: Ask whether the package matters at all
Many base image packages are never invoked by your application. For each finding, answer:
- Is the package present at runtime, or only in a build stage you discard?
- Does your service call it, directly or through a library?
- Is the vulnerable function reachable from a network path you expose?
A multi-stage build often removes the package entirely. Shipping a slimmer final image can retire the finding with no exception.
Step 3: Fill in the record
| Field | Example content |
|---|---|
| Image | Registry path and digest |
| Package and version | As shown in the SBOM |
| Upstream status | No fix as of 19 October, link to tracker |
| Exposure | Package not invoked by the service, no inbound path |
| Other controls | Read-only filesystem, dropped capabilities |
| Watch trigger | Re-scan weekly, alert when a fixed version appears |
| Expiry | 60 days |
Step 4: Wire the watch trigger
The exception should end early when a fix lands. Rebuilding the image on a schedule and re-scanning it means the finding flips from "no fix" to "fix available" without anyone remembering. That is also when the clock on remediation starts.
Step 5: Review at expiry
At the end of the term, repeat the checks. Has the status changed? Has an exploit appeared? NIST SP 800-40 Rev. 4 treats patching as a recurring preventive maintenance activity, and a finding that has no patch yet is still part of that cycle.
Mistakes to avoid
Do not scope an exception to "all images using this base". Digests change, and a new build may include different packages. Scope it to the digest or tag you reviewed and revisit when it rolls forward.
Where Safeguard fits
Safeguard's container scanning lists OS packages and findings per image, and its continuous monitoring can flag when a fix becomes available so the exception can be closed.
Try it yourself
Click through it at your own pace, or open it full screen. Open an image scan and look for findings that show no fixed version, then think about what you would write in each field above.
Quick check
Is no fix available enough reason to except a finding?
It is part of one. You also need exposure analysis, other controls, a watch trigger and an expiry.
Should the exception name the image digest?
Yes. Tags move. A digest ties the decision to what you actually reviewed.
Sources
Last reviewed: 19 October 2026.
