Note: also posted in Security StackExchange as there is a security aspect to this question (sorry for cross-posting).

I'm evaluating Docker images for my development and production setups.

When I research how to do something in Docker, quite often I find answers that include the author's own Docker image. For me, this is not suitable as this hinders the transparency of the solution and uncertainty of reliance on future maintenance by that author. Both of these potential issues have security implications.

While the Docker Hub, can provide a convenient centralised and well-known outlet for publishing one's own Docker images, derived from officials, what would be the advantage of using these unofficial images over the originals.

I am aware of reverse engineering tools, as described in answers on Stack Overflow and that at least some of the unofficial Docker images have an associated GitHub repo that apparently shows how the Docker image was built. But this is an inconvenient level of "indirection" or friction to being really sure (if at all possible) as to the contents of the Docker image.

2 Answers 2


As with most elements of Information Security, there is a balancing act between usability and security; an increase in usability often results in a correlated decrease in security and visa versa.

As a thought experiment...

I can make any server 100% secure by wiping the hard drives, putting it through a shredder and then melting down all of the components parts. It also makes it 0% usable.

Docker Hub is no different, the desire is to make these images accessible for the common good, at the cost of traceability and provenance of the images. Fortunately, there are several tools such as JFrog Artifactory and Sonatype Nexus Lifecycle which enable you to apply governance to any Open Source repository (i.e. Docker Hub, Nuget, NPM, etc).

One aspect that I think Docker Hub gets wrong, that other sites get right, namely NPM, is presenting clear information about what Source Repository an image is generated from, that I suspect is due to the decoupled nature of Docker Images from the source code that generates them.

  • +1 upvote thank you (again) Richard Slater. "One aspect that I think Docker Hub gets wrong, that other sites get right, namely NPM, is presenting clear information about what Source Repository an image is generated from, that I suspect is due to the decoupled nature of Docker Images from the source code that generates them." - astute observation. Do you think that indirect derivation in Docker is by design or an oversight? In addition to your tool links mentioned, there are reverse engineering tools here, too: stackoverflow.com/questions/48228275/… Oct 21, 2019 at 15:17
  • I think it's probably a factor of a npm package is in general exactly what is in the GitHub repository that it is based upon. Whereas a Dockerfile routinely collects software from elsewhere in the internet to build the image, either via FROM statements or through apt-get statements within the Dockerfile. Oct 21, 2019 at 15:20
  • Both answers reaffirm my own personal policy to always use official images. And if I'm going to publish solutions online for others, I will always base these on the original official images and in doing so provide people with a github repo to download to run my solution out of the box. I'll be part of the solution. Rather than offering people hope of a solution to their issue only for them to find it uses a custom image which is opaque and cumbersome to reverse engineer, though possible. Thank you. Oct 21, 2019 at 17:46
  • This is why lando.dev is very encouraging - looking at the code - the Dockerfiles are transparent and use the fundamental primitives of the official Dockerfile from hub.docker.com for respective languages that it supports. Also lando.dev is free, fully open source, with no apparent "drug-dealer"/freemium/starter/"community edition" style roadmap to paid versions. And because of that, I'd be willing to donate to it. Jan 2, 2020 at 11:46

This capability is part of what makes Docker Hub great.

Imagine you have a project that requires a very specific system configuration. For example, you want to use a database, but have a specific configuration for it. Docker Hub will allow you to pull the official image (e.g. MySQL), make your changes (e.g., change the default location the database runs, add scheduled tasks), and push your new image. In this example I can now use my custom image as a base for my development and I do not have to script or manually run these configurations every time I pull.

There are security issues as you have now diverge from the official image. Future updates to the official image will not be updated unless you rebuild with the new official image and push.

Additionally, you are correct in that Docker Hub is somewhat opaque in how these images are generated. Using my above example I could easily decide I want to switch to MariaDB as my base image, and push to something that makes people thing it is MySQL due to the tag. Because of this, I prefer to start with official images whenever possible.

  • +1 thanks @Wesley Rolnick, like Richard Slater, you offer both pros and cons of Docker hub unofficial images. A good read from you, as you champion the convenience concept of Docker hub hosting unofficial images, alongside official ones and then are critical of that championing by outlining the pitfalls in terms of security. Thank you. Oct 21, 2019 at 17:43
  • Regarding the tag, why is the default tag called latest and not default? Latest in itself is also a bit misleading, as an image with no tag specified does not have to reflect that it is the latest image (or inherits from a "latest" image) at all. Oct 25, 2019 at 19:14
  • 1
    @PdC: Could you open this as a question so that others have an opportunity to answer? Oct 28, 2019 at 17:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.