Ten questions come up again and again about secure Docker builds. Short answers: use multi-stage builds, run as a non-root numeric user, pin base digests with an update process, keep secrets in mounts, use a dockerignore file, rebuild often with a fresh pull, and attach an SBOM. Details follow.
The ten answers
| Question | Short answer | Basis |
|---|---|---|
| Why multi-stage builds? | Build tools stay out of the shipped image | Docker multi-stage docs |
| Do I need USER? | Yes, if the service can run unprivileged | Docker best practices |
| Which UID? | An explicit numeric one | Image IDs are not deterministic |
| Pin by digest? | Yes for production, but plan updates | Pinning opts out of automatic fixes |
| Can I pass a secret with ARG? | No, it shows in image history | Dockerfile reference |
| What is the safe way? | A secret mount or SSH mount for one step | Docker secrets guide |
| Does the dockerignore file matter? | Yes, it keeps files out of the build context | Docker best practices |
| How do I get a fresh base? | Use the pull option, and no cache for all layers | Docker best practices |
| Does no cache pull a new base? | No, only the pull option does | Docker best practices |
| Can I attach an SBOM? | Yes, with the sbom option on buildx | Docker attestations docs |
A few more notes
On rebuilds: Docker states that the pull option forces a check for a newer base image, while the no cache option rebuilds all layers from scratch but does not itself fetch a fresh base. Use both for a fully fresh build. For cadence, see rebuilding images regularly.
On attestations: SBOM is opt in, and minimal provenance is on by default. The default docker driver needs the containerd image store for them. See adding an SBOM and provenance.
On the build context: files you do not exclude are sent to the builder and may end up in layers. See what dockerignore keeps out.
What this list does not cover
Hygiene lowers risk but does not remove it. A well built image can still contain a vulnerable dependency, and a clean build does not tell you about run time exposure, network settings or who can push to your registry. Treat these answers as the floor.
Order of work for a team starting out
- Move to multi-stage builds and a non-root user.
- Add the dockerignore file and remove secrets from ARG and ENV.
- Pin base images and set up automated update pull requests.
- Schedule weekly rebuilds with a fresh pull.
- Scan the built image in CI and add a gate for new serious findings.
- Turn on SBOM and provenance for release builds.
Quick check
What is the single highest value change?
For most teams, removing secrets from the image and running as non-root. Both reduce real damage if something goes wrong.
How often should I review this list?
Quarterly, since tools and defaults change. Re-read the current Docker documentation when you do.
Safeguard
Safeguard does SBOM and dependency scanning, and its policies and gates can run in CI so a bad image does not reach production. You can try a free scan before deciding anything.
Sources
Last reviewed: 19 October 2026.
