This is mostly a good post, but he doesn’t mention one huge security disadvantage of containers: When application artifacts all include their own versions of dependencies locked at build time, it becomes very hard to update a component that has a security fix. It’s somewhat tractable if you own all the images — you “just” have to rebuild every application with the vulnerable component. But once you start accepting prebuilt images from elsewhere, you are at the mercy of the external source unless you want to fork the Dockerfiles.

It’s the same lesson that a lot of people learned about static linking, with the zlib vulnerabilities years ago.

https://www.linux.com/news/linux-kernel-netscape-affected-ma...

Good luck with the fork-and-rebuild strategy. It's a maddening process to track down then vendor all the upstream Dockerfiles when you want to use a DockerHub image, but don't trust DockerHub binary images.

I seriously don't get how folks are comfortable with using all these binary layers built and rebuilt from unspecified versions of other binary layers, all shipped with no cryptographic verification by default. (Transport security with SSL is good enough, yeah? sob)

We're in a situation of needing to create a very stringent SDLC + supporting tooling for use in safety-critical software development, and it's sometimes surprising how much of the traditional ecosystem (and thus convenience) we have to opt-out of because of how many layers of weak trust + verification we'd have to be willing to take on the liability for using without meaningful ways to measure how exposed to risk we'd be.

It's thankfully a very interesting problem to have to address, but it does mean that our time-to-market is inherently atypical compared to others.

It’d be a great strategy for Docker, considering what looks like an industry convergence on K8S as an orchestration platform.

Double down on the Dockerfile format and abstract things that would otherwise be frozen in time, taking ownership of some aspects of DockerHub that are currently managed by contributors. They do this already with official language images but there has to be more to it outside of that than expecting people to figure out the intimate details of each base image while keeping them up to date across OS versions and library versions.

I think they are doing something along those lines with linuxkit: https://github.com/linuxkit/linuxkit.