Only if you build the docker images yourself... in which case you have all of the dependencies on your system. If you're not building them, then you are at the whim of every maintainer to rebuild with a fixed openssl.
Most of the time, that rebuild is as simple as "just push a new version"; if the base image is something like Ubuntu 16.04, it will get the update automatically with the next clean build. We already trust the maintainer to write good code that does what I expect; this is just one more thing.
But what you described is literally "the worst case scenario is as bad as before (building my own images), but it would commonly be better". I'll take that any day.
Also, a lot of apps don't need a full linux distro shipped with them. If your binary is statically linked (like, for example, anything written in Go), the docker image can start from scratch, resulting in an image only a few megabytes large and with no issues like you outline.
>But what you described is literally "the worst case scenario is as bad as before
No its not. Before you might just have to rebuild openssl yourself. Now you need to rebuild openssl for every docker image you use and rebuild every one of those docker images.
Guess how many docker images will make or accept TLS connections. That's how many you will need to maintain the infrastructure to build yourself to respond to openssl vulnerabilities if you run any kind of business that requires good security.
Vendoring (the go and container model of shipping software) is great when you work with perfect upstream devs. Otherwise it effectively means you have to build it yourself with patched dependencies for fixes and hope it works.
Wait until you run into a compat issue between the code and a patched dependency and the upstream dev says "won't fix" because you're not deploying the container provided and the security risk isn't addressed because it "doesn't seem that bad".
