Giving food for thought this week are newbie container virtualization startup BanyanOps, who claim to have found that over 30% of official images in the Docker Hub (the central repository for  developers to pull and push container images) are riddled with “high priority security vulnerabilities.” For “non-official” images which are yet to be “explicitly verified,” this number jumps to 40%.

Data for this study was generated by Banyan Collector – an open source tool developed by the startup – as well a service called Banyan Insights. BanyanOps pulled images from the Docker Hub and assessed the packages and the versions installed in them, before running their findings alongside data from  the Mitre, NVD (National Vulnerability Database) and Linux distro-specific databases to identify the images most vulnerable to attacks.

To put these findings into perspective, threat levels were assessed by taking into account both the complexity required to exploit a system, and the potential impact of a vulnerability. Bash menacing ShellShock and OpenSSL hell raiser Heartbleed are both ranked as high, whilst fellow OpenSSL exploit Poodle falls into the “medium” category. Factors such as gcc (which could trigger integer overflow) are classed at “low vulnerabilities.” Among images created this year, BanyanOps reckon that high or medium vulnerable images edge up to nearly 75%.

The official blog, penned by Jayanth Gummaraju, Tarun Desikan and Yoshio Turner, states that, although this study was conducted on the public Docker Hub registry, BanyanOps believes that their results “are very relevant to enterprises that use private registries.” Whilst the trio note that enterprises generally deploy containers continuously “based on golden images that are periodically updated to have the latest packages,” there is still a risk of exploits seeping in.

To counter the risk, BanyanOps council “rigorous operations management practices with real-time monitoring.”  They urge users to scan images for security holes a rebuild according to their findings and advocate the following;

“Any major vulnerability should be identified instantly and there should be an option to trigger an immediate quarantine of susceptible images. The images not only need to be scanned for OS-level package vulnerabilities, but also application-level package vulnerabilities. These processes need to be efficiently integrated into a continuous deployment framework to realize the full benefits of containers while simultaneously maintaining good security practices.”

It should be noted that BanyanOps didn’t publish any results around the security of ISOs, cloud images or installation media, which, as Docker’s Eric Windisch comments, would be “a necessary baseline for having a discussion” for tightening Docker image security, “especially when many Docker images are based on other installation media.” Nevertheless, the findings certainly are worth bearing in mind for anyone tapping into the Docker Hub.

Some of the biggest criticisms of Docker to date have hinged on security issues – notably, the vendors of rival offering ‘rkt’ have been vocal in their concerns around the current model. Although newer releases of the Linux container technology have gone some way to alleviate some problems, as with any maturing system, there is still work to be done. As Lars Herrmann commented earlier this month, the “solid, stable, supported and secure solution for implementation” required for containers to really capture the enterprise is yet to be convincingly established.

 

 

Startup Claims Official Images in Docker Hub are Riddled with Security Holes

About The Author
- Editor of Voxxed.com, focusing on all things Java, JVM, cloud-y, methodical, future-fantastic, and everything in between. Got a piece of news, article or tutorial you'd like to share with your fellow Voxxians? Drop us a line at info@voxxed.com

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>