That sounds like bad software engineering to most, but if each OpenSSL copy was actually in a separate Docker image, reactions would suddenly be much milder I suspect.
There is also the fact that cryptographic libraries that are certified are often on a 2-3 month delay from the non-certified modules. You have to verify that the Host OS's kernel, the runtime that is providing the containing environment, and every single Docker image that is used to run an application, ensure that each application is running in an appropriate FIPS 140-2 mode inside the container, and also verify that every container is being appropriately kept up to date.
Using Docker does not eschew responsibilities you have to ensure that your OpenSSL and other materials is up to date, especially since Docker doesn't give you any protections when it comes to encryption over the wire or encryption with data at rest which is exactly where a cryptographic library with a vulnerability like in the original article leaves a vulnerability where there shouldn't be one.