Yes, to a large extent. Anyone who can pull your image can run docker history and read the command that created each layer, including RUN lines and build arguments. Treat every instruction as public, and keep secrets, internal hostnames and tokens out of the Dockerfile.
What the command shows
Docker's reference says image history shows the layers and build steps that created an image. The default table has five columns: the image ID of each layer, when it was created, the command that created it, the size, and any comment. A no truncate option stops long commands being cut short, so the full text is visible.
The Dockerfile reference adds a warning: do not pass secrets through ARG, because build arguments show up in docker history. Environment values set with ENV persist in the image and can be read with docker inspect.
What can leak
| Where | Typical mistake |
|---|---|
| RUN command text | A token in a curl header or a password in a command line |
| ARG values | A registry token passed to the build |
| ENV values | An API key baked in for convenience |
| Layer file contents | A config file or key copied in, then deleted |
| Internal URLs and paths | Hostnames of private systems in a download step |
Even without credentials, the history tells an attacker which packages, versions and install methods you used, which helps them pick exploits.
Steps to check your own image
- Run docker history on the image with the no truncate option and read every line as a stranger would.
- Run docker inspect and read the environment and labels sections.
- Scan the image for secrets, since file contents in layers matter too.
- If anything sensitive appears, rotate it first, then rebuild with a safe method.
- Add the check to CI so it runs on every build.
How to fix the causes
Use build secrets for credentials, which are mounted for one step and not stored. See build secrets without leaking into layers. Use a multi-stage build so only the output of build steps reaches the final image, and review what the last stage copies. Keep internal URLs out by pulling from a registry or mirror whose name is not sensitive, or by passing nothing identifying into the image.
Does squashing help?
Flattening layers hides the per layer commands, but it does not remove secrets that are in the final file system, and it breaks sharing between images. The reliable fix is not to put the secret there. Rotate any secret that has been in an image you published, because a registry copy may already exist elsewhere.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Does history show deleted files?
It shows the commands. The deleted content may still sit in an earlier layer, which tools can extract.
Is a private registry enough protection?
It limits who can pull, but anyone with pull access sees the history. Still keep secrets out.
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.
