The Security dilemma of Docker Hub

Docker Hub is an online repository for developers to share and collaborate on containers. It is a great service with tremendous potential to empower developers to work more efficiently and create incrementally better work by building on work that has already been done rather than reinventing the wheel from scratch every time. It also introduces some security concerns.

The security issue facing Docker Hub is similar to the issues facing just about any online, public platform. First of all, like the Google Play store it enables ethically-challenged developers to upload malicious content intentionally. Without some sort of gatekeeper to verify and approve containers in the Docker Hub it’s a bit of a “Wild West” scenario where you either have to trust that the container is secure or do your own due diligence before using it.

The second security concern—which is a much more prevalent and ongoing issue—is whether or not containers are maintained once they’re uploaded to Docker Hub. As new flaws or vulnerabilities are discovered that impact containers that have already been created who is responsible for making sure the containers are patched and updated?

A recent report suggests that this is a pretty big problem for Docker Hub. “Surprisingly, we found that more than 30 percent of images in official repositories are highly susceptible to a variety of security attacks (e.g., Shellshock, Heartbleed, Poodle, etc.),” according to a blog post from Banyan. “For general images – images pushed by docker users, but not explicitly verified by any authority – this number jumps up to ~40% with a sampling error bound of 3 percent.”

The situation is probably not any better for private repositories like Docker Trusted Registry. The Banyan post explains that the researchers expect that they’d find similar results if it looked into private registries. “Enterprises typically deploy containers continuously based on golden images that are periodically updated to have the latest packages. Even with these practices in place, enterprises remain susceptible to vulnerabilities; rigorous operations management practices with real-time monitoring are required to ensure security.”

It comes back to that question: Who should be responsible? Once the Docker container is created and uploaded to Docker Hub to be shared with the world is the original developer still somehow “responsible”? Or does it become the collective responsibility of the community? Or is it just incumbent on everyone who downloads or uses containers from Docker Hub to make sure they’re aware of potential security concerns and determine what patches or updates are necessary before using the container?

The awareness piece seems to be the most important. If organizations and developers at least have an understanding that there is a one-in-three chance that the container they’re using from Docker Hub includes known flaws and vulnerabilities they’re empowered to do something about it.

The bottom line is that there are security concerns and you should know that you’re using Docker Hub at your own risk.

Avatar

Tony Bradley

I have a passion for technology and gadgets--with a focus on Microsoft and security--and a desire to help others understand how technology can affect or improve their lives. I also love spending time with my wife, 7 kids, 2 dogs, 4 cats, 3 rabbits, 2 ferrets, pot-bellied pig and sulcata tortoise, and I like to think I enjoy reading and golf even though I never find time for either. You can contact me directly at tony@techspective.net. For more from me, you can follow me on Twitter and Facebook.

Tony Bradley has 45 posts and counting. See all posts by Tony Bradley