A deployment pipeline pushes a new Docker image to production. The image was built FROM ubuntu:latest. What are the security risks of using 'latest' tag?
- A.'latest' resolves to the newest image in the local cache - each build reuses the layers already stored on the runner, and the pull may skip security updates published after the first build. Best practice: clear the cache (docker system prune) before each build and pull the base image from a private mirror on the corporate network to keep patch levels consistent
- B.'latest' disables layer caching - each build may rebuild each layer from scratch, slowing the pipeline and raising registry costs. A new ubuntu:latest could also change the default shell to dash (a /bin/sh behaviour change). Best practice: set the --no-cache flag in CI and keep the base image in a private registry for a fixed bandwidth budget
- C.'latest' triggers the Kubernetes default pull policy for that tag - each restart may pull the image again (a registry rate limit risk), and the node then loses its local layer cache. Best practice: set imagePullPolicy to IfNotPresent in each manifest and let the node reuse its cached layers across restarts to reduce registry traffic from the cluster