Docker Hub has a problem. It’s not entirely unique to Docker Hub because it’s an issue facing just about any public repository. The issue is that flaws and vulnerabilities are discovered after the container images are pushed to Docker Hub but it’s not clear who–if anybody–is responsible for updating or maintaining the images.
I wrote about the security issues in Docker Hub in this blog post:
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.”
Read the full post at ContainerJournal: The Security dilemma of Docker Hub.
- Unlocking Proactive Compliance with Adobe’s Common Controls Framework - October 14, 2024
- Unlocking the Power of Continuous Threat Exposure Management - October 8, 2024
- The ReliaQuest Mindset: A Competitive Edge in Cybersecurity - October 4, 2024
View Comments (1)
One way to quarantine the effects of possible malicious code is micro-segmentation of the network which we adopt in the Pertino solution for docker (http://pertino.com/solutions#plank1049)