Currently, all of them seem to have unpatched components and marked red https://hub.docker.com/r/library/nginx/tags/
3 Answers
Any Linux distribution that is updated to the latest release with all the security patches applied is going to have vulnerabilities. Security patches are often created after the vulnerability is discovered. And every distribution will have some lag from when an upstream library releases a fix until it is incorporated into the distribution. When you drill into many of the listed vulnerabilities, you'll often find that the distribution does not have a patch available yet.
Just because an image contains vulnerabilities doesn't mean that it is exploitable. Often the vulnerabilities are with various included libraries which may not even be called when accessing the container through any of the published ports.
For example, some list exploits that allow privilege escalation from a user to root, but many containers run as root already since the root user has added restrictions and can only access the single app. And other exploits may require a library to parse a file, which if your webserver doesn't parse pictures from unknown sources, it may not be possible to use this exploit against your container.
Personally, I feel that Docker is simply shining a light on an issue that has always existed but has been easy to ignore. Without these reports, people assume that applying all the security patches available means they've fixed every known vulnerability. And without Docker they are running applications on these systems without any isolation between the various applications, making an exploit in one application easy to expand and expose every other application and included data on the same machine.
![](../../users/profiles/351549.webp)
- 5,189
- 1
- 21
- 30
-
I drilled into some of the vulnerabilities and they seem unrelated (e.g. prev version, or even iOS etc), so I guess some part of them is just false positives. – Andrey Apr 14 '17 at 07:32
The images are as secure as their least secure component. All of those images are built from a base image to which dependencies are added and then the application is run. If one of those dependencies is vulnerable, so is the whole stack after that.
You can see exactly which components are vulnerable by looking at the Tags page. For example the official nginx image.
![](../../users/profiles/410093.webp)
- 119
- 2
There are technical arguments to support your question but I believe that ultimately the problem lies with the Devops model in that docker has been designed to help 'Devs' not 'Ops', it's about getting code out of the door and 'ticked off' lists quickly. As of early 2017 docker is still much harder to operate than many more traditional code deployment methods, I'm sure as it matures that'll change but if your focus is always on speed you're always going to miss out on the controls that a good operations team can give you - this being one of them.
![](../../users/profiles/1435.webp)
- 100,240
- 9
- 106
- 238