Expert Reaction On Half Of All Docker Hub Images Have At Least One Critical Vulnerability

By   ISBuzz Team
Writer , Information Security Buzz | Dec 02, 2020 05:06 am PST

It has been reported that a new security analysis of 4 million container images hosted on the Docker Hub repository revealed that over half contained at least one critical vulnerability and thousands contained malware or potentially harmful applications.

Notify of
1 Expert Comment
Oldest Most Voted
Inline Feedbacks
View all comments
Tim Mackey
Tim Mackey , Principal Security Strategist, Synopsys CyRC (Cybersecurity Research Center)
December 2, 2020 1:10 pm

Container images are a combination of an application with operating system elements and supporting frameworks. Development teams creating distributed systems following a microservice or cloud native philosophy will select third-party container images to perform one of two functions. Either the container image is used “as is” to provide a shared service, such as with a database, or will be embedded as a base image to create a new container image. In both situations, the design and security practices of the team creating the original container image have a direct impact on the security of the resultant system.

Put another way, do you trust that a third-party development team has followed security practices that are at least as stringent as those you expect your own team to follow? This is critical given that production operating systems should be hardened and have a minimal attack surface, and that container images typically have operating system components in them. When selecting an image from Docker Hub, a development team is implicitly stating that they trust the security practices of the author of that container image. Such implicit trust is risky from a security perspective, which is why many organisations are now creating hardened container images where the image hardening process is managed by a dedicated team skilled in operating system hardening which is separate from the core development team. These hardened images are then pushed to an internal registry and policies are defined that only allow images originating from hardened images in that internal registry to execute in a production cluster.

Last edited 3 years ago by Tim Mackey

Recent Posts

Would love your thoughts, please comment.x