A container image scan lists vulnerable packages it recognises inside the image. It cannot see how the container behaves at runtime, software compiled by hand, flaws with no published record, or how the cluster around it is configured. Treat a passing image scan as one input, not a verdict on the workload.
What it does cover
Trivy's documentation describes scanning installed OS packages from managers such as dpkg, yum and apk, language packages from ecosystems including pip, npm and gem, and some binaries that embed module information. That is a lot of ground, and it catches the majority of what teams actually fix.
Gaps to know about
Unrecognised software. Trivy notes OS coverage is for official vendor packages, not third party or self compiled software. A tool you built from source in a Dockerfile step may not be matched to any advisory.
Runtime behaviour. An image scan is static. It does not see a process that spawns a shell, a container that talks to an odd address, or a mounted volume that exposes the host.
Unpublished flaws. Scanning uses known records. A new vulnerability will not match until it is published and the database updates.
Reachability. A vulnerable package in the image may never be loaded. The scan reports it regardless.
Deployment settings. Whether the container runs as root, may escalate privileges, or mounts the Docker socket is set in the Kubernetes manifest, not in the image. Trivy's misconfiguration checks cover such settings in manifests, and that is a separate scan.
Secrets in layers. Scanners can find them, but only with the right rules. A secret removed in a later layer remains in the earlier one.
Ways to close the gaps
- Scan manifests with IaC checks, see IaC scanning vs CSPM.
- Use small base images, so there is less software to be unmatched.
- Rescan stored images regularly, since the advisory data changes after you build.
- Add runtime controls such as dropped capabilities and read only filesystems.
- Prioritise findings by whether the vulnerable code is actually used.
A short pre-release list
- Image scanned at build and in the registry.
- Manifest checked for root, privilege escalation and host mounts.
- No secrets baked into layers.
- Base image tag pinned, not latest.
- Owner named for each remaining finding.
Quick check
Does a clean image scan mean the container is safe to run?
No. It means no known issues were matched in packages the scanner recognised. Runtime and cluster settings are separate.
Why are hand compiled tools a problem?
They are not installed through a package manager, so there may be no package record to match against advisories.
Sources
Last reviewed: 19 October 2026.
