In a previous post about Docker, I happened to randomly pick bash as a package shared between the host and containers. I had thought of it as a relatively innocent package, but the choice turned out to be prescient. The bash vulnerability announced today shows just how important even those apparently innocent packages can be.
The truth is that whenever you run code, you need to have an understanding of who’s responsible for it over time. With the Project Atomic model for software delivery, we are also responsible for providing a base image from the upstream distribution, and that base image includes security updates. Are your application vendors on top of bash security updates? It will be interesting to see how rapidly public application containers are updated.
To me, a key goal of Atomic is making use of the flexibility and power of containers – while retaining the benefits of the maintenance model of trusted distributions, and this bash vulnerability shows why that’s important.
Colin Walters 
I think you have the wrong link for Project Atomic, the current link takes me to the Bash vulnerability notification on LWM.
Fixed, thanks!
Although I like how this approach will make it far easier to ship easily runnable applications to users, this will make the whole security situation a thousand times worse, because now every application provider is responsible to keep the whole stack up-to-date and consistent.
Now every running application (container) needs to have an updated base image whereas the current approach just requires the user/admin to update the base OS in a single location.
In the end we’ll have hundreds of outdated application containers with dozens of security-wise dangerous components in them still running because the application vendor didn’t update the base-OS in its application container.
Am I completely wrong here how I understood the Atomic concept?
That’s correct, but there are three mitigating factors:
0) You can use “yum upgrade bash” inside a running container, without waiting for an updated base
1) The process of “rebasing” is not automatic, but the base images should maintain compatibility to make it easier to do.
It would be so much better if rebasing of the base image could be done (semi-)automatic for most situations.
Currently Docker containers always point to a cryptographic hash of the parent right (simplified) ?
Now that Docker images can have image signing, could you use the image signing tag as the parent image in combination with a policy of: only security updates (like single line patches) which have the same ABI/API.
Now I have to admit I’m not even sure that is possible. For example in the past I have seen packages that depend on OpenSSL being updated in Debian when the OpenSSL libraries got updated. Maybe these were more than only security patches ? Or they needed to change how OpenSSL is used to be secure I don’t know.