Docker Community Forums

Share and learn in the Docker community.

Update Strategies for official Docker images

We use the official tomcat image to run our application. Currently tomcat:9.0.41-jdk11-openjdk. This is the latest Tomcat 9 version. But this image is based on the buster image, which has known critical security issues (most of them seem to be fixed in debian 10), but all tomcat images are still based on debian 9. So some of our customers might not be allowed to run our image based on tomcat:9.0.41-jdk11-openjdk. What do you do in such cases? build your own tomcat image based on another image (e.g debian 10). Currently we have the option to switch to tomcat:9.0.41-jdk11-corretto, that has no security issues at all, but i guess there might be situations in future, where we have no option to switch to another official image. Did you already have similar situations like this in the past and how did you fix them? it is mentioned that the ‘official images’ get security updates in a timely manner, but is this only for the app (tomcat) or also for the images it is based on?

Not that I use Tomcat.

But out of curiosity, does “Buster” and “Debian 10” the same?

Also, 9-jdk11-openjdk seems to be based on “Buster”.

Well this is in general not a problem related to tomcat, but related to the underlying base image.
you are right, my fault…buster is version 10. But anyway in the tomcat:9.0.41-jdk11-openjdk (buster) image has currently 4 critical security issues. 3 of them are fixed in an update release, which is not yet present in the currently used buster image. And the fourth critical issue that is present was found in 2019 but is still not fixed. No idea if this will be fixed at all. So what would you recommend then?

One of the ways to do it is to drive this through your CI/CD systems. Once your parent image is built, have something that scans your git repos for images using that parent. If found, you’d then send a pull request to bump to new versions of the image. The pull request, if all tests pass, would be merged and you’d have a new child image based on updated parent. An example of a tool that takes this approach can be found here: .

If you don’t control your parent image, as would be the case if you are depending on the official ubuntu image, you can write some tooling that detects changes in the parent image tag or checksum(not the same thing, tags are mutable) and invoke children image builds accordingly.