A Dockerfile policy gate should block a short list of clear mistakes: secrets passed through ARG or ENV, no non-root USER in the final stage, floating base tags, remote downloads without a checksum, and images on unsupported operating systems. Start in warn mode, then enforce once the noise is gone.
Rules worth enforcing
Each rule below ties back to Docker's own documentation, so the gate is not a matter of taste.
| Rule | Basis |
|---|---|
| No secrets in ARG or ENV | The Dockerfile reference warns ARG values show in docker history, and ENV values persist in the image |
| Final stage sets a non-root USER | Best practices say to use USER if the service can run without privileges |
| CMD and ENTRYPOINT in exec form | Best practices say CMD should almost always use that form |
| Base image pinned by digest or at least a specific tag | Best practices describe digest pinning for supply chain integrity |
| Update and install in the same RUN | Best practices say to always combine them |
| No ADD from a remote URL without a checksum | See ADD versus COPY |
| Base OS release still supported | Scanners cannot warn you about fixes nobody publishes |
Two kinds of check
A static check reads the Dockerfile and catches things like a missing USER line. An image check reads the built result and catches what the file cannot show, such as the effective user, installed packages and findings. Run both. See scanning a Dockerfile or a built image.
Roll out in four steps
- Run the rules in report only mode across all repositories and count violations per rule.
- Fix or exempt the worst ones, and write down exemptions with an owner and an expiry date.
- Turn on blocking for new pull requests first, so old code is not suddenly red.
- Review exemptions monthly and drop rules that never fire.
Keep it fair
A gate that blocks with a vague message gets bypassed. Make each failure say which rule fired, why it matters, and the one line fix. Provide a documented exception path with approval, so urgent fixes are not held hostage to a lint rule.
What a gate cannot do
A passing gate shows the file follows your rules. It does not prove the image is free of flaws, that dependencies are safe, or that deployed containers match the reviewed ones. Pair it with scanning at build and in the registry, and with run time controls.
Pull request flow
Run the checks as a required status on pull requests that touch a Dockerfile, compose file or dependency lock file. Post the result as a comment so authors do not have to hunt for logs.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Should the gate fail on every scanner finding?
Usually not at first. Gate on rules you can fix quickly and on new critical findings, and track the rest as scheduled work.
Who owns exceptions?
A named security or platform owner, with an expiry date, so exceptions do not become permanent.
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.
