The "OS" 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.

In any case: One way to mitigate your concern is to use a distroless image 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.

Another advantage of using a distroless image is that the Docker image size becomes much smaller.

Goggle has written a few words 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 "distroless". Well, a Java application doesn't need a Shell, nor does it need any executables from the OS. It doesn't need grep, find and so on. However, it does need certain OS libraries 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.

Bear in mind that if your Java application actually actively touches the OS (by calling 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 WORA principle.

All in all - for the scenario you depict - I would go with Google's Distroless images rather than using the official openjdk image.