Should a container scan hide unfixed vulnerabilities?

Not by default. Hiding unfixed vulnerabilities makes a report shorter, but it also hides risk you may still need to manage with other controls. A better approach is to show them in a separate group, keep them out of the build gate, and review that group on a schedule.

What "unfixed" means in practice

An unfixed finding is a known vulnerability in a package for which the distribution has not published a patched version. The package may be affected, or the maintainers may have decided not to fix it.

Debian's security tracker documents several states that a scanner may reflect. An issue marked unfixed has no patch yet. An issue marked no-dsa is one the security team does not consider worth a security advisory on its own, and the tracker says such issues are not kept unfixed in general but can be fixed in a point update or alongside a fix for a more severe issue. It also has ignored and postponed sub-states, plus an unimportant state for problems that do not affect the Debian binary package. These are different situations, and a single "hide unfixed" switch treats them the same.

The case for hiding them

• Developers cannot act on a finding with no fix. Alerts they cannot resolve train people to ignore the report.
• A build gate that fails on unfixed items blocks releases for reasons nobody can remove.
• A smaller list makes the fixable items easier to see.

The case against hiding them

• Some unfixed items are serious and exploitable. You may need to mitigate by removing the package, changing configuration, or restricting network access.
• Auditors and customers may ask how you track known issues, and "we hide them" is a weak answer.
• A fix can arrive tomorrow. If the finding was hidden, nobody notices.

A middle path

The point is that "unfixed" is a status, not a priority. Priority comes from exploitation signals and whether the vulnerable code is used in your image.

Record the decision

If you do filter, write down the rule: which flag, who approved it, when it will be reviewed, and what you still track. Put an expiry date on the exception so it returns for review rather than disappearing. A note such as "unfixed items without known exploitation are hidden from the developer view only, and remain in the security view" is clear and defensible.

A worked example: one image, three groups

Imagine an image scan that returns 120 findings. After grouping, the picture looks like this.

The raw number, 120, would frighten people and prompt a blanket "hide unfixed" rule. After grouping, the actionable list for the developer is 9 items, and two items need a security decision. The 70 stay visible to the security team without disturbing anyone's build. The numbers here are an illustration, not a benchmark.

Step by step: set up the filter safely

1. Decide the audience. Developers need the fixable list. Security and compliance need the full list.
2. Create two views from the same scan, not two different scans. One data set avoids arguments about which number is real.
3. Define what "unfixed" means in your tool. Check whether it separates "no patch yet" from "will not be fixed" and from "not affected", because the Debian tracker treats those as different states.
4. Add a check for exploitation signals. If a finding has a known exploitation signal, it leaves the quiet group no matter whether a fix exists.
5. Set a review rhythm. Monthly works for most teams.
6. Write the rule down, with an owner and a date for the next review.

What to do with an unfixed finding that matters

When an unfixed finding has an exploitation signal or sits on an exposed path, you still have options.

• Remove the package from the image if nothing needs it. Multi-stage builds and slimmer bases help here.
• Disable the vulnerable feature through configuration if the package supports it.
• Restrict network exposure of the service.
• Replace the base image with one where the package is absent or already fixed.
• Record an exception with an expiry date and the compensating control.

Each of these is a decision someone made and wrote down. A hidden finding is a decision nobody made.

Questions for a vendor

• Can I view findings with and without unfixed items from the same scan?
• Do you distinguish unfixed from not affected, and where does the label come from?
• Can a filter be limited to certain teams or environments?
• Does the audit trail show who turned a filter on?

Try it yourself

Click through it at your own pace, or open it full screen.

Look at how findings with an available fix are separated from those without one, and think about which group your policy should act on first.

Where Safeguard fits

Safeguard shows fix availability with each finding, supports policies and gates that you set by severity and fix status, and can open fix pull requests when you turn that on. You can try a free scan at gold.safeguard.sh/scan.

Quick check

Sources

• Debian Security Tracker documentation

Last reviewed: 19 October 2026.