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

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.