1. "Don't update system packages" is bad advice. There are base Docker images with out-of-date packages that need security updates. CentOS for example doesn't update their base image for months on end.
2. Given you do want system package updates, you need to deal with Docker caching breaking your security updates. So you need to rebuild your image from scratch, without caching, either every time there is a security update or on a weekly basis. https://pythonspeed.com/articles/docker-cache-insecure-image...
3. Not mentioned: don't use build secrets via ARG.
> "Don't update system packages" is bad advice. There are base Docker images with out-of-date packages that need security updates. CentOS for example doesn't update their base image for months on end.
Generally, if you want to update system packages, rebuild the container make it the new base for you. Updating with every build provides a potentially non-reproducible build.
If you're using a tag like centos:8 that gets updated periodically, you already do not have reproducible builds. This just ensures you get updated packages as soon as possible
It's a tradeoff, yes. You can do more work to rebuild a base image, or you can say "technically have slightly newer version of glibc isn't reproducible but in practice I don't expect that to break anything so I'll live with the risk".
2. Given you do want system package updates, you need to deal with Docker caching breaking your security updates. So you need to rebuild your image from scratch, without caching, either every time there is a security update or on a weekly basis. https://pythonspeed.com/articles/docker-cache-insecure-image...
3. Not mentioned: don't use build secrets via ARG.
Some approaches to secure build secrets:
1. BuildKit supports them: https://docs.docker.com/develop/develop-images/build_enhance...
2. Via the network, which is a hack, but it works: https://pythonspeed.com/articles/docker-build-secrets/
3. Via multi-stage builds, but this destroys caching.