A few more things to consider:

* I've been playing with checkov recently as a way to track Dockerfile quality and best practices

* If you use GitHub, here are some additional considerations

* Use image digests for base images and configure Dependabot to update

* Look into implementing OpenSSF Scorecard and Allstar

* Supply chain security is hot right now. Look into cosign (signing) and syft (SBOM)

* Step Security has a GitHub action to harden the runner. Think of it as Little Snitch for runners

One watch out for me, is containers that use musl libc, like Alpine. There's nothing inherently wrong with musl libc, but it does get a lot less real-world use, so your chances of seeing something odd are higher. Perhaps less so now that Alpine has more broad use, but I have specifically seen issues with java.

I would disagree with "Use Docker Content Trust for Docker Hub".

Docker hasn't been signing official images for the last several years, so turning this on means you'll get the last correctly signed images, which happen to be years out of date.

To make OCI images start faster, use stargz. See the image here:

https://github.com/containerd/stargz-snapshotter

It's a lazy file system for images.

> 9. Use docker-slim to remove unnecessary files

Doesn't this, in practice, make the Docker image size situation worse? Docker caches images in layers and reuses e.g. base layers for all operations. Creating a custom single-layer image for each of your binaries negates all the benefits of the layered caching. You have to download the full image on each pull, rather than just the diffs.

Conversely, when I pull the Docker image for an updated version of my software, I typically only have to pull the last few small layers because the base image hasn't changed.

"update system packages" while this is better for security, it breaks immutability/reproducibility of the end image.