You cut container scanning false positives by removing what the image does not need, scanning the artifact you actually ship, recording justified not affected decisions in a VEX document, and ranking by exploitation evidence and reachability. You will not reach zero noise, and each suppression needs a reason and an expiry date.
A false positive here means a finding that is reported but does not put you at risk. That is different from a wrong match, so the fixes differ.
Why does a clean looking image report so much?
Five causes account for most of the noise. These are our grouping, based on how VEX describes the cases.
The component is not there. A layer inherited from a base image contains packages the application never uses, such as shells and package managers. OpenVEX calls this component not present when the product does not include it.
The component is there, the vulnerable code is not. The package is installed but a build or configuration setting excluded the affected code. OpenVEX calls this vulnerable code not present.
The code is there but never runs. The vulnerable function sits in a library your application never calls. OpenVEX calls this vulnerable code not in execute path.
The match is wrong. The scanner matched a name and version range to a package that has the fix backported or is a different product. This is a true false positive, and a bug report to the scanner vendor is the right fix.
The image is not what you deploy. Scanning a build stage or an old tag reports things that never reach production.
What reduces the noise at the source?
Use a minimal base image and a multi-stage build so only runtime files ship. OWASP's Docker cheat sheet recommends integrating container scanning into the CI/CD pipeline and pinning the base image version and operating system package versions. Pinning makes results repeatable, since the same tag no longer changes under you.
Run as a non-root user, drop capabilities and set read-only filesystems. These do not remove findings, but they lower the impact of the ones that remain, which makes it easier to accept the rest.
Rebuild on a schedule so base image fixes arrive. A finding fixed upstream disappears with a rebuild, and no suppression is needed.
How do you record a decision once?
A VEX document states whether a product is affected by a vulnerability. OpenVEX defines four statuses: not affected, affected, fixed and under investigation. A not affected statement must include a justification, from this list: component not present, vulnerable code not present, vulnerable code not in execute path, vulnerable code cannot be controlled by adversary, and inline mitigations already exist. OpenVEX itself warns that the last two are often hard to prove conclusively, because mitigation bypasses have happened.
CISA publishes minimum elements for a VEX document, so a consumer can read your statement without guesswork.
Treat a VEX statement like a code review: it names an author, a date and the evidence. Set an expiry so it is reviewed again.
Where does reachability help, and where does it not?
Reachability analysis asks whether the vulnerable code is called from your application, which maps to the execute path justification. Safeguard includes reachability analysis. It can be conservative, and it cannot see code loaded by reflection or from plugins at runtime. Use it to rank, and use human review before marking something not affected.
What to do
- Switch to a minimal base image and multi-stage builds, then rescan.
- Scan the exact image digest that is deployed.
- Pin base image and package versions, and rebuild weekly.
- Group the remaining findings by the five causes above.
- For each justified suppression, write a VEX statement with evidence, owner and expiry.
- Gate builds on known exploited or reachable critical findings first, and widen later.
Quick check
Is every not affected finding safe to ignore?
Only if the justification holds. OpenVEX warns that mitigation based claims are hard to prove conclusively. Record evidence and review on an expiry date.
Can I reach zero findings?
Rarely, and it is not the goal. Aim for no unexamined findings: each is fixed, accepted with an expiry or marked not affected with a reason.
Open the full demo at /demos/exploitability-check.
Sources
Last reviewed: 18 October 2026.
