Many Vulnerabilities Found in Popular Docker Images, But Most Are Not Loaded Into Memory
Cloud security company Rezilion has analyzed some of the most popular Docker container images and determined that while they include many vulnerabilities, less than half of these flaws pose an actual risk.
Rezilion’s researchers have analyzed 20 of the most popular container images hosted on DockerHub, the largest library and community for container images. The images they have reviewed have been downloaded between 50 million and more than one billion times.
Each container was scanned using the Vuls vulnerability scanner, which revealed a total of roughly 1,800 known security holes. After identifying the packages containing each vulnerability, the containers were run to determine which files were loaded into memory.
The analysis revealed that packages containing 60% of the identified vulnerabilities were never actually loaded so they did not pose a risk.
Shlomi Boutnaru, the CTO of Rezilion, told SecurityWeek that they used the suggested execution command for each container as shown in Docker Hub, and in reality the number of vulnerable components loaded into memory could be higher or lower, depending on the configuration. However, Boutnaru said the data they collected from their own customers using non-default configurations shows that in many cases the amount of code that remains unloaded is even higher than what their study has found.
Rezilion conducted its analysis twice, in November 2019 and February 2020. The February review showed that 67% of the vulnerabilities rated “high severity” based on their CVSS scores were never loaded into memory, and in November the percentage was 75%.
“If one were prioritizing vulnerability management based on CVSS scores, they would run the risk of spending upward of 70% of their time and effort on vulnerabilities that posed no risk to their production environment,” Rezilion explained in a report shared with SecurityWeek.
“Detection of installed vulnerable components does not edify which code parts utilize them—akin to testing for operating system dependencies that inform which vulnerable libraries are installed, but cannot tell which apps are actually using these libraries. Monitoring which libraries are actually loaded in runtime is the right approach to successful vulnerability prioritization,” the company added.
The correct approach to vulnerability management, according to Rezilion, is to use Gartner’s Continuous Adaptive Risk and Trust Assessment (CARTA) strategy, where decisions and security responses are made based on risk and trust, and continuously adapt to the context and learnings gained from each interaction.
In the case of containers, Rezilion says a CARTA strategy involves identifying the business importance and criticality for services used in production, identifying vulnerabilities that are actually running in them, prioritizing vulnerabilities that have no defenses or compensating controls (e.g. anti-exploitation, IDS, whitelisting tools), and prioritizing flaws commonly targeted by hackers and malware while also considering the criticality of the asset and its external exposure.
Liran Tancman, CEO of Rezilion, told SecurityWeek that collecting the data is not a problem as there are several freely available tools that can be used for this purpose.
“There are a variety of good instrumentation technologies for every OS such as tracepoints, ftrace, SystemTap, Dtrace and more for Linux. The problem is not collecting the data but merging between the high velocities of runtime data to what is pushed by developers/devops teams. It is a very tedious and complex thing to do without automation,” Tancman explained.