A container image scan unpacks the image layers, builds an inventory of the software inside, and matches each package and version against databases of known vulnerabilities. It reports what is installed. It does not run the container or test how it behaves.
The inventory step
Images are stacks of layers, each holding filesystem changes. A scanner reads those layers and identifies the operating system packages, and often language packages such as those listed in lockfiles or manifests present in the image. The result is a bill of materials for the image, which can also be exported as an SBOM.
The matching step
Each package and version is compared with advisory data. The output is a list of vulnerability identifiers with severity, the affected package and, where known, a fixed version.
What a scan covers and misses
| Covered | Not covered |
|---|---|
| OS packages from the base image | Business logic bugs in your code |
| Language dependencies found in the image | Vulnerabilities not yet published |
| Some configuration issues, such as running as root | Runtime behavior and network exposure |
| Known secrets baked into layers, with some scanners | Cluster settings and access control |
| Fixed version hints | Whether the vulnerable code is actually called |
Reading results sensibly
A large count is normal on a general purpose base image. Group findings by layer. Most come from the base, so the fix is often a rebuild on a newer or slimmer base, not hundreds of separate patches. Then rank by severity, whether a fix exists and whether the vulnerable code is reachable from your application.
Steps for a first scan
- Scan the image you actually run, by digest, not a tag that may have moved.
- Sort findings by layer.
- Fix base image findings by updating the base.
- Fix application dependency findings in your manifest.
- Record the accepted risks with an owner and review date.
- Repeat on a schedule.
For a deeper list of blind spots see what container scanning cannot see.
How Safeguard helps
Safeguard provides SBOM and dependency scanning with reachability analysis, and policies, gates and guardrails you can apply before merge. You can try the free scan on a repository.
Try it yourself
Click through it at your own pace, or open it full screen.
See how many findings drop out once unreachable code is set aside.
Quick check
Does an image scan test the running container?
No. It inspects contents at rest. Runtime and network testing is a different activity.
Why do slim images show fewer findings?
They contain fewer packages, so there is less to match against advisories.
Sources
- Docker documentation, Understanding image layers (fetched 19 October 2026).
Last reviewed: 19 October 2026.
