Shameless Plug: I wrote a cli-plugin for docker, docker-lock, to solve the mutable tag problem without having to manually specify hashes - https://github.com/safe-waters/docker-lock
It creates a Lockfile (think package-lock.json) that tracks the image digests (sha256 hashes) of your base images, so you will always know exactly which images you are using even if you only specify tags. This way, you can know if a base image has changed, yet still receive important security updates that you would not receive if you hardcode the digest. It supports any registry, so is useful even if you are not using Dockerhub. It also works with Dockerfiles, docker-compose files, and Kubernetes manifests.
I hope anyone dealing with this issue finds it helpful :)
Incidentally, I've proposed official image annotations[0] that would let an image tell you what its base image is, both by immutable digest and by mutable tag, so you could detect this drift automatically.
Automated tooling could look at these annotations and notify maintainers, or proactively rebuild/rebase when base images change[1].
By having this information on the images themselves, you don't have to deal with as much source repo churn, though you might want that too.
If your app layers have a strong enough contract with your base layers (buildpacks is really good for this!), then you can rebase[2] instead of rebuilding from source.
[0] OCI spec proposal: https://github.com/opencontainers/image-spec/pull/822
[1] Proof of concept in the `crane` tool: https://github.com/google/go-containerregistry/pull/960
[2] https://github.com/google/go-containerregistry/blob/main/cmd...
Despite the idea is interesting, I'm not sure it's the right solution to the problem.
The problem should be fixed upstream, and tag updates should not happen for patch releases.
The biggest issue that I see with Docker is the fact that tags are easily overwritten, and as the author pointed out in the article, a moving tag breaks builds and makes them unreproducible.
I still wonder if there is a cleaner solution than using image digests, this whole trend is going to make the Dockerfile FROM more confusing.
I think GitHub will do this for you now: https://docs.github.com/en/code-security/supply-chain-securi...
Distroless is a misnomer. Any "distribution" of files that has its own build process and unique end state, is a distribution. So, "distroless" containers are still "a distro", it just has less extraneous files. This has some useful properties, but at the same time downsides: bolting-on additional requirements is significantly harder, and development outside of a tightly controlled CI system becomes burdensome.
At the end of the day, any such change comes down to a single principle: the "distance" from development to production. If whatever you do puts more distance between how development is done and how production works, then in the long run it's counter-productive. Call this the "developer distance principle".
I keep track of upstream image changes using https://github.com/crazy-max/diun
... but I also separately ensure all software installed in a docker image is pinned to a version, and have a process I run daily to check whether the upstream packages versions have changed, in which case I rebuild the images which then get the updated (possibly security) version.
It's fiddly, and a lot of bash and perl. I'd welcome a similarly trust-able tooling from a reputable source.
seems like we need the equivalent of a lockfile for dockerfiles. i want to build from a sha256 tag, but I want that to be based on a readable tag which is updated via pull requests by dependabot/renovatebot/etc.
that's essentially what this article is doing, but where is the readable tag stored; is it im source control somewhere? it needs to be, otherwise how can I understand it and update it locally?
Seems like the author is assuming the official images get security updates applied immediately. They don't. So you need to apply system package updates yourself, separately from updating the base image.
https://pythonspeed.com/articles/security-updates-in-docker/ has an example of a security update that was missing in the official Ubuntu base image, two weeks after Ubuntu released the updated package. I've also seen missing security updates in the Debian base images used for things like Python and OpenJDK official base images.
This means that you need to rebuild automatically yourself on a schedule (or as result of distro updates), e.g. https://pythonspeed.com/articles/docker-cache-insecure-image...