It has been reported that researchers from the Norwegian University of Science and Technology (NTNU) put 2,500 Docker images from Docker Hub to the test. In a research paper, the computer security researchers describe how they used the open-source Anchore Engine security scanner and their own scripts to analyse a sample set of 2,500 Docker images. They found about 17.8 per cent (430) of the Docker images contained no known vulnerabilities, or 21.6 per cent (533) if you ignore negligible vulnerabilities.
The Vulnerability Analysis Report highlights a known problem within the world of application containers – pulling a Docker image without knowing its full provenance opens the door to unexpected exposure to unpatched vulnerabilities. Unfortunately, the report unintentionally highlights the challenge of knowing precisely which images should be used for an application. As an example, it highlights the jackson-databind-2.4 and phython-2.7.5 images as having the greatest number of vulnerabilities. While true, it doesn’t state that the current version of jackson-databind is 2.12, and that version 2.4 was released six years ago. It also doesn’t state that all versions of Python 2 are end-of-life and shouldn’t be used in production applications.
This is a variation of the “know the origin of your source” attribute of open source software governance highlighted within the 2020 Open Source Security and Risk Analysis (OSSRA) report. Docker images present on Docker Hub should be treated no differently than the source code used to create them. Open source patch management strategies should have complete visibility into all areas where open source is being used – including from Docker images regardless of the registry. Organisations blind to the origin of the container images used for their production applications cannot claim to have a comprehensive patch management strategy in place.
Of course, patching a container image is different than patching a server or VM, so an effective patch management strategy will require a clear understanding of not only the origins of the image, but also how its orchestrated. Businesses who assume they patch containers using the same tooling they use for VMs or servers will accidentally be increasing the risk to their operations due to the way container orchestrators function.