Review a Dockerfile by reading it top to bottom with twelve questions: which base, pinned how, which user, where secrets go, what is downloaded, what is copied, what is installed, and what the container is allowed to do at runtime. Most problems show up in the first ten minutes.
Base image
- Is the base pinned? The Docker guidance says tags are mutable, and that a digest pins an exact image for supply chain integrity. If you pin a digest, is there an update process for it?
- Is it the smallest base that runs the app? Fewer packages mean fewer findings and fewer tools for an intruder.
- Is it from a source you trust, and one you can name?
Build stages
- Is there a multi-stage build? Build tools should not be in the final stage. See multi-stage builds.
- Is every COPY specific? A broad copy of the whole folder pairs badly with a missing ignore file. See what leaks through the build context.
Secrets and downloads
- Are secrets passed as ARG or ENV? Those persist in the final image. Use build secret mounts. See build secrets.
- Is anything downloaded without a checksum, or piped from curl into a shell? See ADD versus COPY.
Packages
- Is the package index update in the same RUN as the install? The guidance says always combine them, so a cached layer does not hold stale lists.
- Are there tools nobody needs? The guidance says to avoid installing extra packages just because they might be nice to have. Editors, network tools and compilers rarely belong in a runtime image.
Runtime posture
- Is there a USER line with an explicit numeric UID? And is it in the final stage? See running as non-root.
- Does the app work with a read-only root filesystem? If not, which paths does it write? See read-only root filesystem.
- Does anything need extra capabilities, a privileged flag or the Docker socket? If yes, ask why. See the Docker socket.
How to run the review
Print the file and mark each number as pass, fail or unknown. Unknown counts as fail until someone answers it. Then check two things the file cannot show: what the final image actually contains, and how the platform will run it.
Some teams add a Dockerfile linter to the pipeline. The OWASP cheat sheet suggests static analysis of Dockerfiles in the build pipeline, with checks such as requiring a USER directive and a pinned base version, and scanning images for vulnerabilities, secrets and misconfigurations. Automate the repeatable ones so human review can focus on judgment.
What a review cannot catch
- Flaws in the application code and its libraries
- Vulnerabilities disclosed after the build
- Differences between what the file says and what the registry holds
- Runtime settings applied elsewhere, such as in a manifest
For those, scan the built image and keep an inventory. See how often to rebuild.
Click through it at your own pace, or open it full screen.
Safeguard's SBOM and dependency scanning, along with policies and gates, can run checks like these on every pull request. You can try a free scan on an existing image first.
Quick check
Which item catches the most real problems?
Secrets in ARG or ENV, a missing USER line, and an unpinned or oversized base cover many findings. Start there.
Should I block merges on all twelve?
Block on the clear ones, such as secrets in the image and root user, and treat the rest as review comments until you tune the rules.
Sources
Last reviewed: 19 October 2026.
