Containers are frequently being used to bundle up an artifact for end users -- this means they're always going to be service/application, as opposed to librarie

Containers are frequently being used to bundle up an artifact for end users -- this means they're always going to be service/application, as opposed to libraries (which get crammed inside the container). Those libraries still get developed, and still get installed inside the container even if they aren't the "direct" product. Only now, as a sysadmin, I can't easily audit the versions of those packages inside the container, because I have no guarantees on how they were installed. One of the 18 Dockerfiles between `scratch` and `some_application` might install a few bits of software from distro packages from whatever rootfs they decided to base off of. The next layer may download a tarball and extract it over the rootfs to throw down a few more of the app's dependencies. When using software packaged by a distribution like Debian, I'm given pretty strong guarantees that I can always audit the version and integrity of installed software, and that when a bug is fixed in a common library coughopensslcough, I don't have to spend as much time fretting about the places a vendored vulnerable version might be hiding in my infrastructure. That said, I don't mean to disparage use of containers in general: I'm a huge fan of them, I just feel pretty strongly they should be a software deployment tool as opposed to a distribution tool. I get a bit uncomfortable when I can't consistently generate an image "FROM scratch".