Docker Image Security Scanning: What It Can and Can’t Do

Docker image security scanning should be a core part of your Docker security strategy. Although image scanning won’t protect you from all possible security vulnerabilities, it’s the primary means of defense against security flaws or insecure code within container images. It’s therefore a foundational part of overall Docker security.

In this article, we explain how Docker image security scanning works, why it’s important and what its limitations are.

What is a Docker image security scan?

Docker images

To understand Docker image security scanning, you first have to understand Docker images. In Docker, a container image is a file that defines which data and processes should exist inside a particular container when it starts. In other words, it’s a blueprint for the specific application or service that runs inside a given container.

To create a Docker image, you first create a Dockerfile, which is a plain-text file that defines what should be included in a container image. Typically, your Dockerfile will take a Docker base image, which in most cases is some version of a Linux distribution. The Dockerfile will then modify the base image in some way, such as by adding extra packages to it, or defining certain processes to start in addition to those that the base image runs by default.

Once you have a complete Dockerfile, you can turn it into an image using the Docker build command. You can then upload the image to a container registry, which is a repository of container images that can be downloaded when you want to run a container.

Docker image scans

Docker image security scanning is a process for finding security vulnerabilities within your Docker image files.

Typically, image scanning works by parsing through the packages or other dependencies that are defined in a container image file, then checking to see whether there are any known vulnerabilities in those packages or dependencies.

For example, your image might be built with a Dockerfile that includes a stanza such as the following:

RUN yum install -y  https://repo.mysql.com/mysql-community-minimal-release-el7.rpm 

https://repo.mysql.com/mysql-community-release-el7.rpm

This line, which is part of one of the official MySQL Dockerfiles, specifies that containers that are run based on your image should download and install the package mysql-community-release-el7.rpm from the specified URL. (In this specific case, the container uses yum to install the package; if you were working with a Debian-derived base image, you’d likely use apt to install packages. It’s possible to install packages directly from a tarball, too, if you wanted.)

If there were a known vulnerability either in that specific version of MySQL, or in the RPM file used to install it, your Docker image security scanning tool should alert you to that vulnerability. (To be clear, there is no known vulnerability in this version of MySQL at the time of writing; we’re simply using this as an example.) With that knowledge, you’ll be able to update your Docker image to use a secure version of MySQL.

Docker image scanning tools

To perform a Docker image security scan, you need a specialized tool. Some container registries, including Docker Hub and Quay, offer built-in scanners that scan all of the container images inside your registry.

Other image scanners, including Anchore and Clair (the same scanner used by Quay), can be used to scan individual container images even if they are not part of a repository. Of course, one-off scanning is not efficient if you have a large-scale container deployment.

What Docker image security scanning won’t do

While Docker image security scanning is one critical way to find security flaws that could lead to a breach within a containerized application, it’s important to note that security scanning by no means provides full security coverage. There are several potential security problems that Docker security image scanning won’t help you find, including:

Security problems in your container environment or orchestrator configuration

Docker image scanning will do nothing to help identify problems such as containers that are running as root (which is almost never a good idea), or an insecure Kubernetes configuration. You need to use other tools (such as Kubernetes pod security policies) to help protect against these environment-level threats.

Insecure shared resources

Resources that are shared between containers, such as storage volumes or networking, may also have security vulnerabilities due to insecure configurations. Docker security image scanning won’t find these problems, because they exist outside container images.

Unknown security vulnerabilities

In most cases, Docker image scanning tools check public security vulnerabilities databases to determine whether a package has a security problem. Obviously, this won’t help you if you use a package that has a security flaw that has not been publicly disclosed. For this reason, you can’t assume that your packages are safe just because your Docker security image scanner deems them to be so.

Vulnerabilities not evident from a package name

As we’ve noted above, Docker image security scanning works by checking to see whether specific packages that are included in a Docker image have known vulnerabilities. This strategy works well for finding many types of vulnerabilities.

However, a big limitation is that image scanners will not be able to find all potential problems in Docker images which include packages that are not publicly monitored for security vulnerabilities. For example, if you take an open source software package, customize it, rebuild it into a new package, and include that new, custom package in your Docker image, your image scanner will not be able to detect all potential problems in it, because the version of the package that you are using is different from the version tracked in public vulnerability databases.

Similarly, if you include open source code in a container by importing it as a tarball instead of using a package from a public repository, your image scanner probably won’t be able to scan that code, because it won’t recognize it as being part of a known package.

For protection in these types of situations, source code analysis tools like Mend are useful because they can determine the origins of your code, even if it includes a mix of original components and third-party open source code that was imported in bits and pieces into your application.

Conclusion

Docker image security scanning should certainly not be the only part of your container security strategy, but it’s a crucial one. Partnered with other security tools that can help you to monitor your container environment and orchestrator, as well as detect security problems in open source code included in a containerized application in ways that image scanners can’t track, image scanning is a foundational part of container security.