When no fix exists, do not just suppress the finding. Check whether the vulnerable code is present and reachable, reduce exposure, add a compensating control, record an owner and an expiry date, and watch for a patch. A documented decision is better than silence or panic.
Why there may be no fix
A finding has no fix for several reasons. The upstream project may not have released one. The distribution may have marked it low priority. The package may be end of life. Or the fix exists in a newer major version that you have not adopted. Each cause needs a different response, so find out which one you have.
Decision steps
- Confirm the finding is real. Check that the package is actually present, and that your scanner is not matching an upstream version number to a package the distro has already patched.
- Check exploitability. Is the vulnerable function called? Is the service reachable from untrusted input? A VEX statement can record that a component is not affected in your product, which CycloneDX describes as conveying exploitability in the context of the product where it is used.
- Look for a different route to remove it. Can you drop the package, switch to a base image without it, or use a multi-stage build so it never reaches the final image?
- If it must stay, add a compensating control: restrict network access, drop capabilities, run read-only, or remove the feature that uses it.
- Record the decision with an owner, a reason and an expiry date.
- Rescan on a schedule so the finding resurfaces when a fix lands.
Choosing a response
| Condition | Response |
|---|---|
| Package unused at runtime | Remove it from the image |
| Present but code path not reachable | Record a not affected statement with evidence |
| Reachable, internet-facing, exploited | Treat as urgent; isolate, mitigate, consider taking the service offline |
| Reachable, internal only | Mitigate and set a short expiry |
| End of life component | Plan a replacement; an expiry alone is not a plan |
Write good exceptions
An exception should say what the finding is, why it is accepted, who accepted it, which controls reduce the risk, and when it must be reviewed. Without an expiry, an accepted risk becomes permanent by neglect.
Try it yourself
Click through it at your own pace, or open it full screen.
Walk through the exploitability check and note which questions decide whether the finding is urgent.
Quick check
Is it fine to ignore a finding with no fix?
Not without a recorded reason and expiry. Ignoring it silently hides a risk you may later have to explain.
Does switching base image help?
Often. If the package is not in the new base, the finding disappears. Test the change like any other upgrade.
Safeguard offers reachability analysis and policies that help record these decisions; the free scan shows findings for your own dependencies.
Sources
Last reviewed: 19 October 2026.
