Container image scanning
Container image scanning is the analysis of a built image against vulnerability data, to identify the known flaws in the operating system packages and application dependencies inside it. It describes the contents of the artefact at rest and tells you nothing about how that container behaves once it is running.
The scan works by resolving the image layers into a package list and matching it against advisory data, which makes it a form of software composition analysis applied to a filesystem rather than to a manifest. Placing it at the registry and in the build pipeline is standard, and it produces an SBOM for free, which is increasingly what a customer or a regulator asks for.
What the output does not say is the part that matters in an audit. It does not distinguish a vulnerable package that is installed from one that is loaded and reachable, so the count is inflated and teams learn to ignore it. It does not see anything mounted, injected or downloaded at runtime. And a clean scan of an image says nothing about the privileges the container is granted when it is scheduled, which is where the real risk in most Kubernetes estates sits.
Two findings we write repeatedly. Secrets committed into a layer, which remain readable in the image history even after a later layer deletes the file. And a pipeline that scans and reports without a gate, so images with critical findings are published anyway because nothing stops them. Enforcing the gate belongs with an admission controller, and comparing scan results with what the workload actually runs is part of the cloud testing where the running workload is compared with what the scanner reported.