Container scanning: more than vulnerabilities in an image
By Cyso Cloud on
Containers have become the building blocks of modern cloud environments. They are fast, repeatable and easy to move around, but they also carry along something less visible: everything inside them, and everything around them. A container is more than an image. It is a layered image, a set of configuration that determines how that image runs, and ultimately a live process inside the cluster. Container scanning is the practice of checking for security risk across all three of those levels, not just the image. Most teams treat it as a vulnerability check on an image alone, and that leaves real risk unexamined.
Why image scanning only covers part of the risk
An image can be spotless and still run insecurely, because its configuration hands it far too many privileges. A container that was fine at deployment can start behaving strangely once it is running. So container scanning is not a single check. It is three perspectives working together: the image, the configuration around it, and its behaviour at runtime. The table below shows what each layer covers.
Layer | What it inspects | Where it runs | What it catches |
|---|---|---|---|
Image | The contents of the image | CI/CD pipeline, registry, cluster | CVEs, leaked secrets, malware, outdated OS packages, SBOM gaps |
Configuration | Manifests around the container | Kubernetes YAML, Helm charts, Dockerfiles | Root or privileged containers, missing limits, unsafe mounts |
Runtime | The container while it runs | Live cluster | Unexpected processes, odd network traffic, drift from the image |
Layer 1: what does image scanning actually check?
Image scanning inspects what is inside the image, at several points across its life. In the CI/CD pipeline the image is scanned right after the build, before it is published. This is the earliest point where you can block an image on critical findings, before it ever reaches a registry. In the registry, stored images are rescanned on a schedule, because an image that was safe last week can be vulnerable today thanks to a newly published CVE. And in the cluster, what is actually running gets monitored.
This is about more than CVEs. A mature image scan also picks up secrets that ended up in a layer by accident, misconfigurations in the Dockerfile, and sometimes malware. It produces an SBOM too, so you can trace exactly which components live in which image. Here is the part classic dependency scanning tends to miss: it checks your application dependencies, the npm modules, Maven artifacts or Go modules your code pulls in, but not the operating-system and base-image packages underneath them. Things like glibc, OpenSSL or an end-of-life base image sit in that system layer, and they are often the largest unused attack surface you have.
Layer 2: why a secure image is not enough
A secure image tells you nothing about how it runs. Configuration scanning looks at the manifests around the container: Kubernetes YAML, Helm charts and Dockerfiles. Is a container running as root, or in privileged mode, when it has no reason to? Are resource limits missing? Are permissions too broad, or volume mounts unsafe?
With admission control, this layer becomes enforceable rather than advisory. Containers that fail to meet policy are simply rejected at deployment. Detection turns into prevention.
Layer 3: what runtime scanning sees that static scans cannot
The final layer is the container while it is running. Static scans show you the state before deployment. Runtime scanning shows you what happens afterwards. Does the behaviour drift from what the image should be doing? Do unexpected processes or network connections show up? Has the running container drifted from the original image?
This is detection over time, not detection at a single moment. It is also where container security starts to overlap with security operations, because you are watching live behaviour rather than a snapshot.
From detection to control
Three scanning layers produce a lot of signal. But data is only worth anything when you do something with it. Scans that dump hundreds of unfiltered findings mostly cause alert fatigue, and the urgent stuff gets lost in the noise. That is why processing matters as much as the scan itself. Findings are centralised, deduplicated, weighted by severity and context, and then routed deliberately into follow-up.
The Cyso Cloud team uses a variety of open-source projects such as Trivy on top of Kubernetes to achieve this. That keeps the solution lightweight and vendor-independent, and it fits neatly into an existing Managed Kubernetes environment rather than bolting something foreign on top.
Learn more about our Managed Kubernetes serviceA building block for security operations
Put the three layers together, image, configuration and runtime, and you get a continuous stream of telemetry. That is exactly what a security operations function needs to spot risk early and act on it on purpose. The static layers tell you what is lined up. The runtime layer tells you what is happening right now. Centralise those signals, correlate them, and connect them to alerting and response, and container security stops being a set of isolated checks and becomes a coherent operational picture.
That is the direction our Tech, Product and R&D teams are working towards: from detection to detection and response. The point is not to scan more. It is to move from volume to signal, turning findings into context, priority and action, so a future SoC layer can build on input that is reliable and scales. Container scanning is not the finish line here. It is the foundation: the automated sensors that a broader security operations chain is built on.
Schedule a free discovery call
