Security in The Container Registry

Top ten Docker images contain over 8000 vulnerable paths

| By Hayley Denbraver

Introduction

In this post, we’ll look deeper into Docker images and the container ecosystems that were covered in our State of Open Source Security report, including our finding that the top ten Docker images contain over 8,000 vulnerable paths.

We are excited to help our community better understand Docker security. Since the previous State of Open Source Security was released, Snyk has released tools to help developers understand and mitigate container vulnerabilities. We love to not only share our insights into the state of open source security, but also to provide tools to help you find and fix the vulnerabilities in your container images.

Try scanning your container vulnerabilities now!

Through our research for our State of Open Source Security report, we observed the following statistics regarding who owns container security and who actually practices it.

  • 68% of users feel that developers should own the security responsibility of their docker container images.
  • 54% of developers don’t do any docker image security testing.
  • Only 15.5% of the users claim to test their Docker images for vulnerabilities during development.

These points suggest that there is a disconnect between who owns security and how it is practiced. Since developers own container image security, they would benefit greatly from incorporating security earlier in their workflow, during development–but only 15.5% are doing so! The numbers also suggest that there are developers who own security but are not actively practicing it. This means that even low-hanging fruit—vulnerabilities that can be fixed by updating the base tag or by rebuilding the docker image—may end up ignored.

For these reasons, we thought that it would be a good idea to look at the vulnerabilities we found in more depth, to help developers understand the security issues relevant to their docker containers.

Docker security deep dive

We are taking a closer look at vulnerability paths, how dependencies relate to vulnerabilities, and vulnerability severity.

A quick note: these numbers are current at the time of this writing, so they vary slightly from the numbers presented in the State of Open Source Security report.

Paths to vulnerabilities

Sometimes a particular vulnerability is introduced via multiple dependencies. Snyk did not want to count these vulnerabilities multiple times, as that would give the impression that the image is much less secure than it actually is. However, it is important to understand that a vulnerability can be introduced multiple times because the more dependencies it is associated with, the harder it could be to remediate. To give the user an idea of how often this occurs, Snyk uses the concept of “paths”, which describe how many ways the image vulnerabilities are introduced. For this reason, I thought it was a good idea to understand the ratio of paths to vulnerabilities to get a general sense of how difficult it might be to remove vulnerabilities from the given Docker image.

Table shows how many paths each vulnerability has.
We can see from this table that the node Docker image is likely to be the most difficult from which to remove vulnerabilities. We can also tell that every vulnerability present in all 10 surveyed images is likely to have more than one path associated with it. Fortunately, Snyk helps you to not have to unravel these knots yourself. Our Docker tools can help you determine how to remove these vulnerabilities or suggest other Docker images to use instead.

Dependencies

Now, let’s look deeper into the dependencies for each of the Docker images. The following table gives us an understanding of how the number of dependencies corresponded to the number of vulnerabilities.

Table shows how many dependencies are present in each image.

When we consider the ten Docker images we studied as a whole, we observed for every ten dependencies added, we are likely to see seven vulnerabilities introduced. Node is an outlier here, introducing on average 14 vulnerabilities for every 10 dependencies added–twice the rate of the average!

Severity

Snyk categorizes vulnerability severities as high, medium, and low. These categories help users triage and prioritize which vulnerabilities to fix first. Understanding the severity of the vulnerabilities found in the Docker images gives us a better idea of the scope of the security problem.

There is good news with respect to vulnerability severity! By far the majority of the vulnerabilities observed in our study were rated as low severity, accounting for 74.9% of vulnerabilities. Medium severity vulnerabilities accounted for 16.9%, followed by high severity vulnerabilities at 8.2%. This is good news because users can prioritize the small number of high severity vulnerabilities and make a large impact on the security of their container.

The breakdown by Docker image for vulnerability severity is as follows: 

We can see that, although there is variation between the individual Docker images, there is a general trend for the majority of the vulnerabilities to be low severity. This is good news!

Conclusions

Our findings that the top ten Docker images contain over 8,000 paths to vulnerabilities, coupled with the observation that for almost every dependency present in these images a vulnerabilities was added, make a strong case for using minimal base images. This recommendation was also our #1 security practice from our recently published cheat sheet for Docker security.

By preferring minimal images that bundle only the necessary system tools and libraries required to run your project, you are also minimizing the attack surface for attackers and ensuring that you ship a secure OS. This means potentially fewer vulnerabilities, fewer paths to those vulnerabilities, and fewer overall dependencies–all resulting in a more secure container.

Docker security can be complicated, but Snyk’s tools make it easy to remediate vulnerabilities and find a more minimal base image. Try it today!

Try scanning your container vulnerabilities now!