That's hilarious simply because most heavy Docker users I've interacted with basically use it as a way to build houses of cards which glue-sticked piles and piles of dependencies together rapidly.
This is largely because application complexity in some domains and expectations of development pace have ballooned to insanity but there are plenty of heavy Docker users that do this even when these sort of pressures don't exist.
I think as software progresses and more development techniques become easier to leverage and automated (correctly and incorrectly), we're getting to a point advanced statistical software packages have been at for quite some time: no matter what data you throw at the software for analysis and what analysis you choose, the software has so much experience baked into it that you'll get some result that makes assumptions what you're doing is valid that may look like reasonable outputs even if they aren't. If you do need to do some preprocessing, much of that is even automated so it's incredibly easy to do something very wrong if you dont know what you're doing but not realize it. Automation has made it much easier to fail late instead of fail early.
Docker isn't the disease, its use in such manner is just a symptom.
"Allow CRUD of names" ok, you'll have it next sprint. "Allow upload of their resumé docs" no problem, two more weeks. "Parse the docx and PDF files users upload and extract the contents and fill our db schema with relevant data". Well shit. The specs to understand either of those formats are gigantic and now I'm forced to cobble together something using more dependencies if you want it done in less than two year's time.
If, for example, a file format is really complex, it has most likely one implementation that almost everyone uses. If there is a problem with it, you will hear about it. Use that.
On the other hand, if a file format is really simple or you only need a simple subset of it, rolling your own could avoid you getting 0-dayed when the most popular implementation has a vulnerability.
vs getting hit when your vulnerable implementation becomes popular. Not an obvious choice indeed.
Which is not going to happen, because there's no point in publishing something that is tailored to your specific purpose.
Also, good luck doing static analysis on binary tools.
There's an entire area of work people call "ops" that specializes on managing that dependency. But they can only do that if it's dynamic and loosely coupled.
You make your own images, if you really care. You involve your "ops" people in that.
They manage the base images that are then used by your dev team. They're responsible for updating the base images.
Your dev team provides a CI/CD pipeline which the ops team can use to check that security updates don't break functionality.
It's not rocket science.
Docker is like shipping EAR + Websphere + OS in one package.
For jars/dlls you look up dependency scanners and hook them up to your CI/CD.
For Docker images you look up image scanners and hook them up to your CI/CD.
Hot-patching apps to use newer versions of JARs because of security bugs, outside of the update stream of the actual app itself, is not really a good idea due to the risk of regressions. Docker has basically codified the failure of dynamic linking in the real world.
Do you think Java .jars in Maven repos or .NET .dlls in Nuget are faring any better?
Find solid dependencies, don't use too many of them, make sure you update them, use static analysis tools and dependency scanners, etc. Same drill as for anything.