Container scan shows hundreds of vulnerabilities: what to do first

Start by finding out where the findings come from. Most of a long report usually sits in the base image and in packages your app never calls. Update the base image, remove what you do not need, then triage what is left by severity, exploitability and reachability.

Step 1: separate the layers

Split the report into operating system packages from the base image, language packages from your application, and anything you added by hand. Each has a different owner and a different fix. A report of 400 findings is often 350 base image items and 50 yours.

Step 2: refresh the base image

Rebuild on the current patch release of your base image. Many findings disappear simply because a fix was published since your last build. Pin by digest after you choose, so builds are repeatable, and rebuild on a schedule.

Step 3: shrink the image

Every package in the image is something that can be flagged. Use a smaller base image, a multi stage build that leaves compilers and build tools behind, and remove package caches. Fewer packages means fewer findings and a smaller attack surface.

Step 4: triage what remains

Ask three questions of each finding:

• Is a fixed version available?
• Is it known to be exploited, or likely to be?
• Does your application actually use the vulnerable code, or is the package present but unused?

Fix the ones that say yes to the first two now. Schedule the rest.

Step 5: record decisions

For findings you park, write the reason and a review date. That way next week's scan does not restart the argument.

What not to do

Do not suppress a whole severity band to make the number look better. Do not stop scanning because the count is discouraging. The aim is a list short enough that a person can act on every line.

Try it yourself

Click through it at your own pace, or open it full screen. Look at how findings group by layer and notice how few need action once you apply a fix filter.

Quick check

Last reviewed: 19 October 2026.