On the Relation between Outdated Docker Containers, Severity Vulnerabilities, and Bugs

Abstract

Packaging software into containers is becoming a common practice when deploying services in cloud and other environments. Docker images are one of the most popular container technologies for building and deploying containers. A container image usually includes a collection of software packages, that can have bugs and security vulnerabilities that affect the container health. Our goal is to support container deployers by analysing the relation between outdated containers and vulnerable and buggy packages installed in them. We use the concept of technical lag of a container as the difference between a given container and the most up-to-date container that is possible with the most recent releases of the same collection of packages. For 7,380 official and community Docker images that are based on the Debian Linux distribution, we identify which software packages are installed in them and measure their technical lag in terms of version updates, security vulnerabilities and bugs. We have found, among others, that no release is devoid of vulnerabilities, so deployers cannot avoid vulnerabilities even if they deploy the most recent packages. We offer some lessons learned for container developers in regard to the strategies they can follow to minimize the number of vulnerabilities. We argue that Docker container scan and security management tools should improve their platforms by adding data about other kinds of bugs and include the measurement of technical lag to offer deployers information of when to update.

ConPan: A Tool to Analyze Packages in Software Containers

“…They offer isolation, portability and reusability by providing all needed artifacts and dependencies shipped in one package. However, as shown in previous research [4], [27], [18], Docker containers may contain vulnerable and outdated packages that may put at risk the environments where the containers are deployed. Nevertheless, little support is given to practitioners and researchers desiring to assess the status of their containers, thus forcing them to resort to the tedious task of writing error-prone ad-hoc scripts.…”

“…The dataset contains different information related to software packages installed in containers, thus providing a powerful basis to perform empirical studies. As an example, we have used ConPan in previous work [27], where we empirically analyzed installed system packages in a large dataset of Docker Hub images that are based on the Debian Linux distribution.…”

“…If practitioners wish to evaluate other aspects than security vulnerabilities, such as evaluating the outdatedness or quality issues of a container (e.g., in terms of the bugs [12] and available releases [13] of its system and third-party packages), they are forced to develop ad-hoc scripts which may be time-consuming and error-prone. This limitation also affects empirical research in software container mining [14], [15], [16], [17], [18], requiring scholars to reinvent the wheel because of the need to retrieve and analyse the data by themselves.…”

Handling Duplicates in Dockerfiles Families: Learning from Experts

“…The list of these official projects is available on GitHub, with 138 official projects, as of March 2019. 10 Some of these projects share a same Github repository. For example, InfluxDB and Chronograf are maintained in the same GitHub repository.…”

“…They also indicate that the RUN instruction is the most commonly used instruction in Dockerfiles which can be linked to our results in Section V-A where we indicate that RUN instructions are the most frequently duplicated. Zerouali et al [10] perform an empirical analysis on 7,380 official and community Docker images that are based on the Debian Linux distribution. They look at the relation between outdated containers and vulnerable and buggy packages.…”