You probably shouldn’t be using Ubuntu base images anyways. The closer you can get to “scratch” the better, and the fewer security related issues you’ll have. For most use cases I think Alpine is a much better base image.

That's more about trust and faith in the maintainers of the distribution (that they won't screw up).

It's about having the minimal number of system packages and libraries that your app actually needs.

Alpine is leaner so attack surface is thinner.

This. If you start adding stuff to "FROM scratch", you are creating your own obscure Linux distro. When you screw up, there are no other customers to report bugs to you, much less other maintainers to help.

You really shouldn't be adding stuff to "FROM scratch" unless you have one statically linked binary and maybe some config files or something like that. If you actually need packages, you should use something like Alpine if possible.

> At the time of writing, every single image is labelled with "This image has vulnerabilities".

The majority of those are not applicable in any way to your average container. I would highly encourage you to not attempt to make points off such bad data. See below for why I think it's bad data.

I'd also like to point out that those CVEs are even more of a pointless thing to make such a point with since almost all of them aren't fixed in upstream ubuntu... which is to say an ubuntu server with 'unattended upgrades' would be just as 'vulnerable' as these docker containers, except moreso because more of them would actually be relevant in such an environment.

Your overall point is valid, but your reference to those 'vulnerabilities' is egregiously misleading.

Let me analyse as a human all the so-called "critical vulnerabilities" listed there for Xenial:

1. glibc 2.23-0ubuntu10 - CVE-2018-6485

This is exploited by C code which intentionally calls posix_memalign or aligned_alloc (instead of malloc) with unusually large arguments. There are very few codebases out there which make use of that in the first place.

If your container is not running untrusted code which links against libc, you have little to fear. This CVE will not impact the average container running some ruby or nodejs application.

Ubuntu also offers no update yet, so it's not actionable.

2. ncurses 6.0+20160213-1ubuntu1 - CVE-2017-10684, CVE-2017-10685

Only affects you if you're piping un-sanitized user input into an ncurses application which then displays it. I doubt there are many, if any, server applications that do this.

Also not actionable.

3. shadow 4.2-3.1ubuntu5.3 - CVE-2017-12424

I'm sure there are plenty of containers out there shelling out to "newusers" with totally unvalidated input. Highly critical I'm sure.

4. cryptsetup 1.6.6-5ubuntu2.1 - CVE-2016-4484

This one only impacts the initrd of luks encrypted setups.... literally impossible to accomplish in a container. Completely garbage listing, no value, cannot possibly impact a docker container.

5. systemd 229-4ubuntu21.2 - CVE-2018-6954

This requires 'systemd-tmpfiles' to run after an attacker has manipulated the filesystem. 'systemd-tmpfiles' is not run in docker containers, and even if it did, since it starts from a fresh root filesystem each time it's a moot point since any changes the attacker makes won't persist to the next time the container "reboots" and tmpfiles runs (assuming the rare case it's run for some reason as part of the container's boot up).

Another non-applicable one.

6. util-linux 2.27.1-6ubuntu3.4 - CVE-2018-7738

This one's a bug in bash-completions for umount, which aren't installed in the container by default. This one's a false positive because the vulnerable code (the bash-completions script) is not present in the docker image.

You are are right with all you're saying here.

I was not suggesting that `docker build` executed at a given time point is less secure than `unattended-upgrades`. My point in referencing the vulnerabilities was to simply show that there is a constant stream of vulnerabilities that you need to keep patching, and that picking a new base image "every now and then" isn't enough. `unattended-upgrades` just makes it trivial to automate following this constant stream of updates, while with Docker you have to manage that yourself.

Yes, most CVEs don't affect your use case and operations, independent of via Docker or full OSs. But every now and then there is a severe CVE in that stream that affects you. You don't know when it's coming.

There are two ways to be safe: Automatic upgrades, or reading through / subscribing to the CVE stream and analysing everything that passes by (as you demonstrated here; that takes real effort and you need to be awake when it happens). Most people don't do the latter.

who has an app that they don’t deploy daily?

Some of us have contractual obligations not to deploy during the week, and require us to notify and receive permission from our customers for out of band deployments.

Many - and our deploys on weekends are almost zero.

I highly doubt that anyone would deploy everything daily. Your own code, maybe. But what about dependencies? Do you upgrade your Postgres container daily?