<p>I am working to containerize our spring boot microservice based application using docker.</p>
<p>While trying to write the docker image I have noticed about base OS.</p>
<p>What is the industry standard to deploy docker containers to production environments using official images from docker hub.</p>
<p>eg:oracle/open jdk</p>
<p>Will the official images take care vulnerabilities and fixes?...Do we have to take care vulnerabilities in base OS as well?.</p>
<p>Note:We are regularly performing OS patching in host OS</p>

<p>The &quot;OS&quot; on which a Docker Image is based is user-land stuff only, so not really an OS in the the traditional sense. You cannot compare the risk of not keeping that one fully updated with the risk of not keeping a real OS fully updated.</p>
<p>In any case: One way to mitigate your concern is to use a <a href="https://github.com/GoogleContainerTools/distroless" rel="nofollow noreferrer">distroless image</a> as recommended by Google. The reason is that your application is Java-based, it doesn't really need all that user-land stuff from whatever Linux distro.</p>
<p>Another advantage of using a distroless image is that the Docker image size becomes much smaller.</p>
<p>Goggle has written a <a href="https://github.com/GoogleContainerTools/distroless#cve-and-patching" rel="nofollow noreferrer">few words</a> on how they keep their distroless Docker images updated. Google is basing their images on Debian. You may wonder why there's a base OS mentioned, in this case Debian, when at the same time claiming that the image is &quot;distroless&quot;. Well, a Java application doesn't need a Shell, nor does it need any <em>executables</em> from the OS. It doesn't need <code>grep</code>, <code>find</code> and so on. However, it does need certain OS <em>libraries</em> to be there. And these libraries need to come from somewhere, in this case Google has chosen Debian. For you as the consumer of the image it is completely irrelevant that it is Debian.</p>
<p>Bear in mind that if your Java application actually actively touches the OS (by <a href="https://docs.oracle.com/javase/8/docs/api/java/lang/Process.html" rel="nofollow noreferrer">calling</a> an external OS command from within Java) then you cannot use the distroless strategy. But very, very few Java applications do that and most Java devs would consider it an anti-pattern as it violates the <a href="https://en.wikipedia.org/wiki/Write_once,_run_anywhere" rel="nofollow noreferrer">WORA</a> principle.</p>
<p>All in all - for the scenario you depict - I would go with Google's Distroless images rather than using the official <em>openjdk</em> image.</p>
