What is container image scanning?
A container image is a filesystem plus configuration, and scanning it means unpacking the layers and examining both: the OS and application packages inside (matched against known vulnerabilities), any secrets baked into layers, and the image configuration itself - root users, dangerous capabilities, unsafe defaults. Scanning at build and at the registry catches problems before they run and as images age.
A container image is the unit modern software ships in: a layered filesystem containing an operating system slice, your application, and everything it depends on, plus configuration describing how to run it. Container image scanning unpacks that artifact and examines all of it - because each part carries its own class of risk.
The three things a scan examines
The packages inside. Every image embeds an inventory nobody assembled deliberately: OS packages from the base image, language dependencies installed during the build, tools copied in along the way. Scanning identifies these packages across the layers and matches them against known vulnerabilities - which makes the base image you chose, and how long ago you chose it, a security decision. The inventory itself is emitted as an SBOM, which is also what enables monitoring the image after it ships.
The secrets baked in. Build processes leak credentials into images with depressing regularity: tokens copied in for a build step, configuration files with passwords, keys in a layer that a later step “deleted.” Because layers are additive, that deletion hides nothing from anyone holding the image - which is why serious scanning is per-layer and reports secrets that no longer appear in the final filesystem.
The configuration. The image also declares how it runs: which user, which capabilities, which entrypoint. Containers that run as root, request dangerous capabilities, or expose debug surfaces are misconfigurations of the image itself, catchable before any cluster is involved - and distinct from the manifest-level checks that govern how the cluster is told to run the image.
Where scanning belongs in the pipeline
Two points, doing different jobs:
- At build, as a CI step after the image is created: fail the push on new critical vulnerabilities, embedded secrets, or disallowed configuration, so the registry only ever receives images that passed. Deterministic scanning is what makes this gate trustworthy enough to keep enabled.
- Against the registry, on schedule, because images age in place: the image is unchanged, but new disclosures land on its packages weekly. Rescanning (or re-evaluating stored inventories against updated vulnerability data) catches the drift.
Scanning works on the artifact - archives, registry references, or a local daemon - so no cluster agent is required, and third-party and vendor images can be held to exactly the same standard as your own, which is a quietly important property for supply chain accountability.
In the SecuNexa platform
SecuContainer is the platform’s image engine: it unpacks images from archives, daemons, or registries entirely offline, produces the package inventory as CycloneDX, reports secrets per layer, checks image configuration, and sends everything to the dashboard where vulnerability matching and policy live.
Frequently asked questions
Why do images need rescanning if they have not changed?
Because the world changes around them. An image built months ago contains the packages of its build date, and new vulnerabilities are disclosed against those packages continuously. A registry rescan, or re-evaluating the image's stored inventory against updated vulnerability data, is how yesterday's clean image is caught carrying today's critical CVE.
Why are deleted files in earlier layers still a problem?
Image layers are additive: deleting a file in a later layer hides it from the running container but the file still exists in the earlier layer, retrievable by anyone with the image. A secret added and then deleted during a build is therefore still shipped. Per-layer scanning reports these; a scan of only the final filesystem misses them.
Do I need an agent in my cluster to scan images?
No. Image scanning targets the artifact: an archive, a registry reference, or a local daemon's store. That keeps clusters untouched, works in airgapped environments, and means the same scan runs identically in CI, at the registry, and on a laptop.