On Docker Image CVE Fixes and Prevention

Rules of thumb:

ensure your image have a proper security software-upgrade source configured - so apt-get upgrade (or the equivalent) doesn’t do nothing.
Include RUN apt-get update && apt-get upgrade -y (or the equivalent) in your Dockerfile.
Schedule your own rebuild weekly or monthly.

Background #

The single source of truth for Docker official images (DOI) is the master branch of https://github.com/docker-library/official-images. They use a format called “Library definition files” to define which tags in which repository should be actively rebuilt and where to find their Dockerfile (git repository URL and commit ID). These repo:tags are called currently maintained ones.
- Most but not all of these referenced Dockerfile git repositories are maintained by Docker Inc. itself. For an example.
A Jenkins job at https://doi-janky.infosiftr.net/ analyzes Dockerfiles of all DOIs, generates up-to-date dependencies among DOIs, and persists them to https://github.com/docker-library/meta.
Using these metadata, every merged PR to a DOI Dockerfile triggers a rebuild and push to Docker Hub of all its downstream DOIs (those that FROM it) on https://doi-janky.infosiftr.net/.
- Scheduled unconditional rebuilds are not guaranteed.

Observations #

Docker Inc.’s DOIs do not RUN apt upgrade (or the equivalent) in the Dockerfile, nor are other DOI vendors required to do this.
Even if a DOI vendor has the OS upgrade step in their Dockerfile, if there is no scheduled unconditional rebuild, security patches (if any) will not be installed.
Some DOIs use a distro where security update upstream is disabled by default. See docker run --rm mysql:9.6.0 tail /etc/yum.repos.d/oracle-linux-ol9.repo for an example.

Consequently, currently maintained DOIs provide no guarantee of being CVE-free at the time of the build. Therefore, a no-op rebuild (without RUN apt upgrade or the equivalent) will not fix anything.

References: