Analyzing Packages in Docker images hosted On DockerHub
Download as PPTX, PDF0 likes36 views
The document presents research on the outdatedness, vulnerabilities, and bugs in Docker containers. It analyzes over 7,000 Docker images and finds that over half have not been updated in four months. Packages in unofficial images tend to be more outdated than official images. All official Node.js-based images contain vulnerable npm packages, with an average of 16 vulnerabilities per image. Older images generally have more outdated and vulnerable packages. The researchers conclude that tools are needed to help Docker users update their packages and containers. Future work could expand the analysis to other ecosystems and create a tool to assess package outdatedness and vulnerabilities in Docker containers.
![/Method
/Identifying Analyzed
Images
base:image Dockerfile
FROM scratch
ADD rootfs.tar.xz /
CMD ["bash"]
LAYER Y
LAYER X
build](https://image.slidesharecdn.com/saner19docker-190625233246/85/Analyzing-Packages-in-Docker-images-hosted-On-DockerHub-13-320.jpg)
Analyzing Packages in Docker images hosted On DockerHub
- 1. On the Relation between Outdated Docker Containers, Severity Vulnerabilities, and Bugs Ahmed Zerouali, Tom Mens, Gregorio Robles, Jesus Gonzalez Barahona The IEEE International Conference on Software Analysis, Evolution and Reengineering (SANER) Hangzhou, China - February 24-27, 2019
- 2. On the Impact of Outdated and Vulnerable Javascript Packages in Docker Images Ahmed Zerouali, Valerio Cosentino, Tom Mens, Gregorio Robles, Jesus Gonzalez Barahona The IEEE International Conference on Software Analysis, Evolution and Reengineering (SANER) Hangzhou, China - February 24-27, 2019
- 3. /Background
- 4. /Background
- 5. /Background
- 6. /Goal A method to assess how vulnerable, buggy and outdated Docker images are with respect to the latest available releases of the packages they include.
- 7. /Technical lag 1.0.1 1.1.0 2.0.01.2.1 2.1.0 Dependency Software Project Technical lag Ideal Version - Ideal Version: stability, security, functionality, etc. - Technical lag: version updates, commits, bugs, vulnerabilities, lines of code, etc.
- 8. /Method /Technical lag in Docker 1.0.1 1.1.0 2.0.01.2.1 2.1.0 installed package: P Docker container C Technical lag - technical_lag (P) = { ∆ versions, ∆ vulnerabilities, ∆ bugs}
- 10. /Method /Case Study/Debian - Docker containers based on Debian
- 11. /Goal /Research Questions RQ 0 : How often are Docker images updated? RQ 1 : How outdated are container packages? RQ 2 : How vulnerable are container packages? RQ 3 : To which extent do containers suffer from bugs in packages? RQ 4 : How long do bugs and security vulnerabilities remain unfixed?
- 12. /Method /Process
- 13. /Method /Identifying Analyzed Images base:image Dockerfile FROM scratch ADD rootfs.tar.xz / CMD ["bash"] LAYER Y LAYER X build
- 14. /Method /Identifying Analyzed Images Instantiated Dockerfile FROM base:image ……… …………….. LAYER Y LAYER X LAYER Z build
- 15. - All official repositories - 30,000 community repositories (+500 pulls) 2,453 images 4,927 images /Method /Identifying Analyzed Images
- 17. /Method /Identifying installed packages $ docker run <image> $ dpkg -l A median of 190 and 261 packages in official and community images, respectively.
- 18. /Method /Package info and Vulnerability and Bug Reports - Package info - Vulnerabilities - Other Bugs - Debian Archive - Debian Security Tracker - Ultimate Debian Database
- 19. RQ 0 : How often are Docker images updated? More than half of the Docker images have not been updated for four months.
- 20. RQ 1 : How outdated are container packages?
- 21. RQ 1 : How outdated are container packages?
- 22. RQ 2 : How vulnerable are container packages?
- 23. RQ 2 : How vulnerable are container packages?
- 24. RQ 3 : To which extent do containers suffer from bugs in packages?
- 25. RQ 3 : To which extent do containers suffer from bugs in packages?
- 26. RQ 4 : How long do bugs and security vulnerabilities remain unfixed?
- 27. RQ 4 : How long do bugs and security vulnerabilities remain unfixed?
- 28. On the Impact of Outdated and Vulnerable Javascript Packages in Docker Images Ahmed Zerouali, Valerio Cosentino, Tom Mens, Gregorio Robles, Jesus Gonzalez Barahona - Docker containers based on Debian
- 29. /Goal /Research Questions RQ 1 : How Outdated are npm packages in Docker images? RQ 2 : How vulnerable are npm packages in Docker images?
- 30. /Method /Case Study/npm - Official images - Node based images 961 unique official Docker images as candidates - Layering mechanism
- 32. /Method /Identifying installed packages $ docker run <image> $ find .. package.json A median number of installed packages is 200, 419 and 959 for node, mongo-express and ghost, respectively.
- 33. /Method /Package info and Vulnerability Reports - Package info - Vulnerabilities - Libraries.io dataset - Snyk.io.io DB (1,099 vulnerability reports)
- 34. RQ 1 : How Outdated are npm packages in Docker images? At the date of the last update of the Docker image: Median version lag = 0 major + 0 minor + 1 patch
- 35. RQ 1 : How Outdated are npm packages in Docker images? At the date of the analysis (March 13th 2018): Median version lag = 1 major + 1 minor + 4 patch
- 36. RQ 2 : How vulnerable are npm packages in Docker images? - All official node-based images have vulnerable npm packages, with an average of 16 security vulnerabilities per image. - Older images are more likely to have more vulnerabilities.
- 37. /Limitations - The results of our results are not generalizable. - The results depend on the on the datasets and databases from where we extracted the data. - In the case of npm, we only found a limited number of vulnerability reports. - There are other ways in which we can compute the technical lag.
- 38. /Conclusion - Debian and npm packages in Docker containers. - Old images have more outdated packages. - The number of outdated packages is correlated with the number of vulnerabilities. - Package update recommendation tools are needed in order to support Docker deployers.
- 39. /Future Work - Carry out other analysis for other ecosystems. - Create a tool to assess how outdated and vulnerable packages in Docker containers are, including both system and third-party packages. - Gather monthly snapshots about Docker containers in order to analyze their evolution.
Editor's Notes
- #4: In June 2015, ClusterHQ asked enterprises “What are the biggest barriers to putting containers in a production environment?” a higher percentage of enterprises (>60%) said that security was the #1 barrier to putting containers in a production environment.
- #5: After some time, In August 2015, FlawCheck and one of our partners, surveyed enterprises asking which piece of the security equation was their top concern about running containers in production environments. At 42%, Vulnerabilities & Malware in container workloads was the top container security concern among those surveyed. Later on, A 2016 survey by DevOps.com and RedMonk, revealed that users who are more concerned by image security focused on scanning simple Common Vulnerabilities and Exposures (CVE) on the operating system.
- #6: later, in 2017, a survey by Anchore.io focused on the landscape of practices being deployed by container users [1]. One of the questions was: “Other than security, what are the other checks that you perform before running application containers?” The top answers related to software package were: required packages (∼ 40% of the answers); presence of bugs in major third-party software (∼ 33%); and verifying whether third party software versions are up-to-date (∼ 27%)
- #7: For this reason, we decided to support container deployers by creating a method to asses…...
- #8: To do so, we relied on the concept of technical lag, the was introduced as the difference between the software version that is deployed and the ideal version available but not deployed yet.
- #9: For this reason, we rely on the notion of technical lag as the difference….
- #10: We decided to work with Docker images based on a Linux distribution, because applications in them are usually installed using well-defined packages. Among them, we selected Debian because of its maturity and widespread use 1 in DockerHub. On October 1st 2018, the Debian repository on DockerHub had more than 125M pulls 2 .
- #11: We decided to work with Docker images based on a Linux distribution, because applications in them are usually installed using well-defined packages. Among them, we selected Debian because of its maturity and widespread use 1 in DockerHub. On October 1st 2018, the Debian repository on DockerHub had more than 125M pulls 2 .
- #13: The overall process, which we describe in detail below, is: (1) identification of Docker Hub base images for Debian, defining our base set; (2) identification of Docker Hub images in our dataset, including those derived from the base set; (3) analysis of all those images, matching their packages to a historical archive of all Debian packages; and (4) identification of bug and vulnerability reports for those packages, based on a historical database with those details for Debian packages.
- #14: We base ourselves on the mechanism of layering in Docker.
- #15: We base ourselves on the mechanism of layering in Docker.
- #18: We pulled and run all images and then used dpkg -l
- #31: We decided to work with Docker images based on a Linux distribution, because applications in them are usually installed using well-defined packages. Among them, we selected Debian because of its maturity and widespread use 1 in DockerHub. On October 1st 2018, the Debian repository on DockerHub had more than 125M pulls 2 .