Container image vulnerabilities explained

Although much of the conversation around container security today has shifted toward the security requirements of orchestration platforms like Kubernetes, not all container security risks can be addressed at the orchestration level. You must also manage threats to individual containers.

The best way to do this is to follow the standard Docker security practices that date back to the early days of Docker containers, which became publicly available in 2013. Although the container ecosystem today has evolved into much more than Docker (indeed, Docker itself is no longer a part of many containerized application stacks, which instead use other runtimes and other orchestration solutions), the fundamental principles of Docker security – like container scanning, container vulnerability management, and container access control – still apply.

Toward that end, this article goes back to the basics by providing an overview of the main categories of container vulnerabilities, along with the measures businesses can take to manage them.

Container image vulnerabilities

Image vulnerabilities remain the most prevalent type of security threat to individual containers. A container image vulnerability is a security risk that is embedded inside a container image. While vulnerable images themselves don’t pose an active threat, if containers are created based on a vulnerable image, the containers will introduce the vulnerability to a live environment.

Container image vulnerabilities typically arise from insecure libraries or other dependencies that are imported into a container image. Images could also contain malicious code that was inserted during a software supply chain attack or similar breach of the development environment.

Detecting image vulnerabilities with container scanning

Fortunately, most container image vulnerabilities can be detected relatively easily via container scanning. Container scanning is the deployment of automated tools that compare the contents of each container to a database of known vulnerabilities. If they determine that a library or other dependency within a container image is subject to a known vulnerability, they will flag the image as insecure.

The major limitation of container scanning is that it’s typically not useful for detecting unknown vulnerabilities, meaning those that have not yet been publicly disclosed or otherwise made available to security analysts. In other words, if your container image uses a library that has a security bug but the “good guys” have yet to discover the bug, container image scanners won’t detect it because the bug won’t be recorded in the vulnerability databases that they use. Vulnerabilities that affect custom, proprietary code are also not likely to be detected because such vulnerabilities are not publicly tracked.

While container image scanning is one vital step toward securing containers, then, it’s important to keep in mind that it’s just that – one step, not a complete vulnerability management solution.

Malicious container images

Although legitimate container images can (and often do) contain vulnerabilities, malicious images that attackers deliberately design to masquerade as legitimate images are an even greater risk to Docker image security. By uploading an image that contains malware to a public container registry like Docker Hub and giving it a name (like mysqldatabase or nginxserver) that sounds legitimate, attackers may trick unsuspecting admins into deploying malicious versions of publicly available software.

Avoiding malicious images

Docker image scanners may not catch these images if they contain malware that is not associated with a publicly disclosed vulnerability. For that reason, the best way to protect yourself from malicious images is to ensure that you only download images from trusted sources. Avoid unofficial Docker Hub registries or GitHub repositories.

You should also avoid using the “latest” tag when pulling container images. Instead, specify an image version. This mitigates the risk that attackers may slip a malicious image into an otherwise legitimate container registry and, by giving it a version number that is more recent than the other images, tricking people into using it.

Privilege escalation threats

Even if all of the container images that you deploy are vulnerability-free, a breach could occur due to a privilege escalation attack.

In a privilege escalation attack, processes that are supposed to be able to access only the resources inside a given container “escape” the container and access resources in other containers or the host server.

Preventing privilege escalation

The main vector for privilege escalation attacks is bugs in either the container runtime software, which is responsible for executing containers, or the host operating system.

Thus, the primary means of defending against privilege escalation is to secure the container runtime and the host operating system. You do this mainly by ensuring that all of the software running on your host server (or servers) is up-to-date and free from known vulnerabilities.

You can also reduce the risk of a privilege escalation attack by deploying a kernel-hardening framework, like AppArmor or SELinux. These frameworks impose additional access controls (based on policies that you configure and apply) to the host operating system, providing a second layer of defense against processes that escape the containers in which they are supposed to live.

Finally, choosing a minimalist operating system, such as Alpine Linux, can mitigate the risk of container privilege escalation by reducing the number of libraries and services that an attacker could potentially exploit. As a best practice, your host OS should include no software other than the bare minimum required to deploy, orchestrate, monitor, and secure containers. If you want to run other workloads along your containers, do it on a different server or VM.

Application vulnerabilities

No matter how secure you make your container images and the environment in which they run, you’ll face security issues if the application that you host using containers contains flaws inside its source code.

For example, insufficient data input validation could enable attacks like SQL injection, allowing attackers to access sensitive information. Or, a buffer overflow vulnerability could enable attackers to execute arbitrary code and take over your container (and, possibly, the entire host).

Managing application vulnerabilities

Because application vulnerabilities occur within application code rather than in any of the processes or tooling associated with containers, you’ll need to manage application vulnerabilities at the application level.

Scan your application source code for vulnerabilities as part of your CI/CD pipeline using Static Application Security Testing, which can identify poor coding practices that could enable threats. Test the application again prior to deployment using Dynamic Application Security Testing, a method that monitors an application running in a sandbox environment to detect behavior that could signal a security vulnerability.

Here again, kernel-hardening frameworks like SELinux and AppArmor can also help to reduce the risk of application vulnerabilities by making exploits harder to execute. But these resources don’t address the root cause of application insecurities.

Using Docker CIS Benchmarks

While there’s no way to guarantee total freedom from container security threats, a helpful way to establish a baseline is to measure your containers’ configurations against the Docker security benchmarks from the Center for Internet Security, or CIS.

The CIS container security benchmarks address all layers of the container software stack. They establish best practices for securing the host, configuring permissions within container images, configuring the container runtime, and much more.

So, while complying with CIS’s recommendations doesn’t guarantee Docker security, it’s worth taking the time to walk through the benchmarks and ensure that you meet each one.

Deploying secure containers in a secure environment requires tools and practices that can mitigate a variety of threats. From container image scanners, to kernel-hardening frameworks, to application security and beyond, you’ll need a broad set of defenses to minimize the risk of security vulnerabilities within containerized application environments.

Learn more about Container Security Best Practices and Tips on: