How is a Container Scan Done?

Containers offer many benefits, including lightweight portability from one environment to another, but they add a layer of complexity to Docker container security and application protection that can introduce additional risks.
There are many ways a container can become vulnerable: through its source code, build process, configuration, secrets management, and interactions with the host and other containers—all potential container vulnerability entry points.  Each of these avenues has its own security solutions and best practices.  While many of those solutions could be called “container scans,” let’s focus on one common scan: scanning container images for open source components, which are typically the largest source of vulnerabilities found within the code itself. This blog post is part of a series about container security.

Container images defined

A container image is a template for building containers and includes source code or binary, dependencies, runtimes, configuration settings, and everything needed to interact with the host kernel—making it the foundation for docker image security. You can think of a container image as all of the ingredients and tools needed to bake the same kind of cookie as many times as you like. The baked cookies are the containers. Like cookies, containers get consumed and are no more, but you can hold onto a container image to create more containers whenever you want. Another way to look at a container image is that it is simply a container at rest, and thus a container is a running container image.

 A container image is built into multiple layers based on each line of its Dockerfile, and each layer is also an image (just not one that has a very human-friendly name). The advantage of these layers is that they can reuse code from one image to another.
But as these images are reused, components can become outdated and insecure. Regular docker image scanning helps detect and patch those weaknesses before they spread.

3 steps to scanning container images

In practice, most new images are built from existing bases found in registries like Docker Hub. These parent images often carry inherited flaws that a container scan can reveal early.
Not all public images are equal—even trusted ones can contain docker container vulnerabilities or outdated packages that put your deployment at risk. Any vulnerabilities present in these base (also called “parent”) images will be inherited, and any new open source packages added by developers will also be a possible source of vulnerabilities.

A container image scan looks at a particular image, layer by layer, for all open source packages and their dependencies. It then creates a list—basically, a software bill of materials (SBOM). That list is then used to cross-check public and private databases for known flaws—a process most modern Container security tools automate.
A container image scan can surface hundreds of issues; pairing it with container security best practices ensures you act on what’s actually exploitable. However, the process itself is fairly straightforward: 

1. Find what’s there.

A container vulnerability scan will identify which open source components exist in an image and where they reside in each layer. Keeping track of which layer of the image those components are on. That might sound trivial, but even the slimmest images will have many open source components that are potential avenues for an attack.

2. Find what vulnerabilities are present.

Once complete, a container scan will give you a list of all of the known vulnerabilities present in the image. As these images are built of many, many open source packages and dependencies, this list is usually quite large and is not particularly useful without additional contextual information.

3. Prioritize vulnerabilities by risk.

Prioritize vulnerabilities by risk using context-aware container security tools that weigh exploitability, severity, and runtime exposure. In the last step, each vulnerability’s weight can be determined using severity and exploitability score such as CVSS and EPSS. This helps security teams choose what to update or patch, and just as importantly, on which layer those vulnerable components reside. Some scanning tools even recommend safer base images or flag vulnerabilities in running Kubernetes workloads—helping teams align scans with kubernetes security best practices, which would make it a higher priority for fixes or replacement than images that are not running.

Best practices: Container image scanning 

The fundamentals of container security best practices remain consistent across architectures. As with any other type of application, shifting left and scanning container images in the development process to catch vulnerable components early provides a number of benefits, including less time and fewer resources spent to fix security issues.
Container images should also be scanned before deployment as part of QA, and after release as part of continuous kubernetes security monitoring. But new vulnerabilities pop up all the time, and just because an open source component is free from vulnerabilities when you build or deploy, doesn’t mean it will remain that way. Container images should be scanned regularly, even after deployment, with automated checks that detect new CVEs and trigger update Docker images workflows for timely remediation.

Continuous scanning, frequent updates, and layered defense across containers, registries, and clusters—supported by Docker container security, kubernetes security, and modern Container Security Scanning—form the foundation of a resilient DevSecOps strategy.