Top ten most popular docker images each contain at least 30 vulnerabilities

Welcome to Snyk's annual State of Open Source Security report 2019.This report is split into several posts:

• 88% increase in application library vulnerabilities over two years

• 81% believe developers should own security, but they aren’t well-equipped

• Open source maintainers want to be secure, but 70% lack skills

• Top ten most popular docker images each contain at least 30 vulnerabilities

• ReDoS vulnerabilities in npm spikes by 143% and XSS continues to grow

• 78% of vulnerabilities are found in indirect dependencies, making remediation complex

Or download our lovely handcrafted pdf report which contains all of this information and more in one place.

Download the 2019 Open Source Security Report

Known vulnerabilities in docker images

The adoption of application container technology is increasing at a remarkable rate and is expected to grow by a further 40% in 2020, according to 451 Research. It is common for system libraries to be available in many docker images, as these rely on a parent image that is commonly using a Linux distribution as a base.

Docker images almost always bring known vulnerabilities alongside their great value

We’ve scanned through ten of the most popular images with Snyk’s recently released docker scanning capabilities.

The findings show that in every docker image we scanned, we found vulnerable versions of system libraries. The official Node.js image ships 580 vulnerable system libraries, followed by the others each of which ship at least 30 publicly known vulnerabilities.

Snyk recently released its container vulnerability management solution to empower developers to fully own the security of their dockerized applications. Using this new capability, developers can find known vulnerabilities in their docker base images and fix them using Snyk’s remediation advice. Snyk suggests either a minimal upgrade, or alternative base images that contain fewer or even no vulnerabilities.

The fix can be easy if you’re aware. 20% of images can fix vulnerabilities simply by rebuilding a docker image, 44% by swapping the base image.

Based on scans performed by Snyk users, we found that 44% of docker image scans had known vulnerabilities, and for which there were newer and more secure base image available. This remediation advise is unique to Snyk. Developers can take action to upgrade their docker images.

Snyk also reported that 20% of docker image scans had known vulnerabilities that simply required a rebuild of the image to reduce the number of vulnerabilities.

Vulnerability differentiation based on image tag

The current Long Term Support (LTS) version of the Node.js runtime is version 10. The image tagged with 10 (i.e: node:10) is essentially an alias to node:10.14.2- jessie (at the time that we tested it) where jessie specifies an obsolete version of Debian that is no longer actively maintained.

If you had chosen that image as a base image in your Dockerfile, you’d be exposing yourself to 582 vulnerable system libraries bundled with the image. Another option is to use the node:10-slim image tag which provides slimmer images without unnecessary dependencies (for example: it omits the man pages and other assets). Choosing node:10-slim however would still pull in 71 vulnerable system libraries.

Most vulnerabilities originate in the base image you selected. For that reason, remediation should focus on base image fixes

The node:10-alpine image is a better option to choose if you want a very small base image with a minimal set of system libraries. However, while no vulnerabilities were detected in the version of the Alpine image we tested, that’s not to say that it is necessarily free of security issues.

Alpine Linux handles vulnerabilities differently than the other major distros, who prefer to backport sets of patches. At Alpine, they prefer rapid release cycles for their images, with each image release providing a system library upgrade.

Moreover, Alpine Linux doesn’t maintain a security advisory program, which means that if a system library has vulnerabilities, Alpine Linux will not issue an official advisory about it; Alpine Linux will mitigate the vulnerability by creating a new base image version including a new version of that library that fixes the issue, if one is available (as opposed to backporting as mentioned).

There is no guarantee that the newer fixed version, of a vulnerable library will be immediately available on Alpine Linux, although that is the case many times. Despite this, if you can safely move to the Alpine Linux version without breaking your application, you can reduce the attack surface of your environment because you will be using fewer libraries.

The use of an image tag, like node:10, is in reality an alias to another image, which constantly rotates with new minor and patched versions of 10 as they are released.

A practice that some teams follow is to use a specific version tag instead of an alias so that their base image would be node:10.8.0-jessie for example. However, as newer releases of Node 10 are released, there is a good chance those newer images will include fewer system library vulnerabilities.

Using the Snyk Docker scanning features we found that when a project uses a specific version tag such as node:10.8.0-jessie, we could then recommend newer images that contain fewer vulnerabilities.

Known vulnerabilities in system libraries

There is an increase in the number of vulnerabilities reported for system libraries, affecting some of the popular Linux distributions such as Debian, RedHat Enterprise Linux and Ubuntu. In 2018 alone we tracked 1,597 vulnerabilities in system libraries with known CVEs assigned for these distros, which is more than four times the number of vulnerabilities compared to 2017.

As we look at the breakdown of vulnerabilities (high and critical), it is clear that this severity level is continuing to increase through 2017 and 2018.

Continue reading:

• check out Snyk’s DevSecOps Hub for resources and tips you can implement.

• Maven Central packages double; a quarter of a million new packages indexed in npm

• 88% increase in application library vulnerabilities over two years

• 81% believe developers should own security, but they aren’t well-equipped

• Open source maintainers want to be secure, but 70% lack skills

• ReDoS vulnerabilities in npm spikes by 143% and XSS continues to grow

• 78% of vulnerabilities are found in indirect dependencies, making remediation complex

• 10 Docker Security Best Practices - details security practices that you should follow when building docker base images and when pulling them too, as it also introduces the reader to docker content trust.

• Are you a Java developer? You’ll find this resource valuable: Docker for Java developers: 5 things you need to know not to fail your security

• 10 best practices to containerize Node.js web applications with Docker. If you’re a Node.js developer you are going to love this step by step walkthrough, showing you how to build secure and performant Docker base images for your Node.js applications.