How is a Container Scan Done?
Table of Contents
Containers offer many benefits, including lightweight portability from one environment to another, but they add a layer of complexity to application security that can introduce additional risks.
There are many ways a container can become vulnerable to attack: through its source code, how the container is built, how the container is configured, how it secures secrets, and how it interacts with the host and other containers. 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.
Container Images Defined
A container image is a template for building containers and includes source code or binary, dependencies, container runtimes, configuration settings, and any other things necessary to both create the container and the interface with the host kernel.
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 time goes on and these images or layers are reused, the software components within them may become outdated and insecure. That is one reason container scans are so important.
3 Steps to Scanning Container Images
In practice, most new images will be built up from existing images found in image libraries such as Docker Hub. Not all public images are of equal quality, and even images from trusted sources can come with vulnerabilities. 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 pull public and private vulnerability information for each component.
A container image scan provides a wealth of information, sometimes an overabundance. However, the process itself is fairly straightforward:
1. Find what’s there.
A container vulnerability scan will tell you which open source components are present in an image, 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.
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 can also suggest more secure images to use or tell you if a vulnerable image is currently running in a Kubernetes cluster, 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 best security practices are usually the same, no matter the architecture. 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, of course, be scanned again before deployment as part of QA processes.
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 they are deployed, so teams can be alerted when new security issues arise.
Secure containerized applications
About the author
