Usually a gate should not block on findings that have no fix, because the developer has nothing to do. But do not hide them. Track them separately, apply mitigations where you can, and block when the flaw is exploited and reachable.
Why blocking on unfixed findings backfires
A gate asks a developer to take an action. When the finding has no patched version, the only options are to remove the package, wait, or add an exemption. If that happens on every build, people exempt by habit and the gate loses meaning.
Scanners usually offer a switch for this. One open source scanner documents its ignore-unfixed option as shorthand for ignoring several statuses: affected, will not fix, fix deferred and end of life. With it on, the output shows only vulnerabilities that have a fix.
The cases where you should still act
| Case | Suggested handling |
|---|---|
| Unfixed, not reachable, not exploited | Hide from the gate, keep in a watch list |
| Unfixed, reachable, not exploited | Mitigate (config, network, feature flag), set a review date |
| Unfixed, known exploited | Block or remove, or document a compensating control |
| Marked will not fix by the maintainer | Plan a replacement, because waiting will not help |
| End of life component | Put it on the upgrade roadmap with an owner |
Notice the status labels in that scanner doc. "Will not fix" and "end of life" are not the same as "fix not yet available". The first two mean waiting is pointless.
Steps to configure it
- Turn on the unfixed filter for the blocking gate only.
- Run a second, non blocking report without the filter, weekly.
- Add a rule that overrides the filter for known exploited findings.
- Review the watch list monthly, since a fix may have shipped.
- Record any mitigation you rely on, with an owner.
A fix can appear overnight
The unfixed list is not static. When a maintainer releases a patch, an item moves from the watch list to the gate. If your gate runs on every pull request, that finding will suddenly block unrelated work. Warn teams about this by running the weekly report and opening pull requests for fixes as they become available.
Try it yourself
Open the demo and look at how a fix being available changes a finding's status and next step.
Click through it at your own pace, or open it full screen.
Safeguard can open fix pull requests when a patched version exists. This is off by default, with every category set to Manual until you change it. Try the free scan at gold.safeguard.sh/scan.
Quick check
Does ignoring unfixed findings hide risk from auditors?
Not if the weekly unfiltered report exists and is kept. The evidence shows you saw them and chose a handling.
What if the maintainer will not fix it?
Plan to replace or fork the component. Waiting for a fix that is not coming is not a control.
Sources
Last reviewed: 19 October 2026.
