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.

I worked on a code signing library years ago that fed data to safety critical systems. Other than the one coworker who suggested we add a sign-off step where we manually verified the SHA-1 hashes (which caught that we had recompiled one of the libraries ourselves, oops!) I had to defend my decision to check all of the dependencies into version control and manually update them.

This class of problems has been around for ages, the noise is just getting louder every day.

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.

Removing as many layers as possible is one way to mitigate this: adding a static binary in a `FROM scratch` container, for example, where all libraries are compiled from sources that you verify the best you can.

Love this comment. And especially with compiled languages like Go and the multiple build stages feature in Dockerfiles, this makes it incredibly easy to do just that.

One thing I forgot to mention is that you are still trusting trust – the builder needs to be verified for the output to be verified.

True, but really the verification problem isn't nearly as bad as the fact that people are running perfectly valid year-old images with year-old vulnerabilities permanently ensconced.