On the (in) security of docker images :Part I

Docker images are currently the most popular implementation of container virtualization aka “application containers”. Application containers are rapidly being adopted in enterprise IT infrastructures due to several advantages including short development and deployment cycles, resource efficiency through lightweight virtualization, availability of tools for automating processes and cross-platform possibilities. Docker images are core building blocks for microservices and container-based infrastructures.

Figure 1: Major Security Risks Impacting the Core Components of Container Technologies

However, container-based infrastructure introduces several security risks such as embedded malware, stale images and untrusted images. Interestingly, these risks are prevalent in different components of the container technologies e.g. images, registries, orchestrators, containers, and host operating system (see Figure 1). Owing to the peculiarities of each these components, overcoming these security challenges requires container-aware security tools that effectively consider each component carefully. Unfortunately, traditional security mechanisms are not very helpful in overcoming these security risks. I’d like to go through these security risk categories as shown in Figure 1, through a series of blog posts. Thus this post will be the first part, note that this categorization is based on the NIST Application Container Security Guide. We will take a look at the first category: image security risks. Key questions to be answered are:

• What are Docker image risks?
• What are the appropriate countermeasures for these risks?

Image security risks include the following:

• Image Vulnerabilities: Essentially, images are composed of static archive files that include components required to run applications. For example, the Dockerfile in Figure 2 will build a Docker image when executed. The image will include python2.7-slim as well as other software packages specified in the requirements.txt file. These software packages might be missing security updates, at build time or after the image is built. Unfortunately, unlike normal software, automatic updates are not possible since images are immutable.

Figure 2. Example Dockerfile for building a python application

• Image configuration defects: Images are also prone to configuration defects. For example, an image may include a tomcat server configured with the default username and password, essentially exposing the container to inquisitive hackers. Similar to classical hosts or VMs, where wrong configurations expose fully up-to-date systems to attacks, poorly configured images also increase risks.
• Embedded malware: Software components packaged in Docker images could also contain malware, which could be intentionally or unintentionally included. Malware embedded in images essentially has the same capabilities (access and privileges) as other packages included in the image, and thus could be used to attack other containers or hosts within the environment. These weaponized images are usually made available to unsuspecting users on public image repositories like DockerHub .

Recent research by Synk revealed several important lessons about the current security state of Docker images. The key take-aways from this research are :

Figure 3: Top 10 most vulnerable official docker images on DockerHub (source: Synk.io)

• The top ten most vulnerable official Docker images in DockerHub include node, httpd, postgres and nginx (Figure 3).
• Each of the top ten images has at least 30 vulnerabilities each, with the node image being the top offender with more than 500 vulnerabilities!
• As many as 44% of Docker images are infected with vulnerabilities that had been already removed in newer versions of their base image.

The best practice for mitigating Docker image security risks include the integration of security scanning in the development pipeline as well as continuous scanning in production environments. Essentially, this calls for continuous security practices, in line with the already established continuous development, and continuous integration.

A continuous security strategy for container-based infrastructure is detailed in our research paper presented at SecureComm 2018. In the paper, we discuss how our cloud-native tool CAVAS (Cloud Aware Vulnerability Assessment System) effectively tackles the aforementioned security risks. CAVAS employs event-driven methods to monitor Docker images all through applications life-cycles. CAVAS is well adapted to handle microservices and cloud-native applications using several innovative concepts.

More discussions on Docker image security will follow in subsequent posts. That’s all for now, thank you for reading!