No. Squashing an image merges layers into one, but the packages and files in the final filesystem remain, so a scanner that reads the filesystem still finds them. What squashing removes is layer history, which makes it harder to tell which build step added a vulnerable package.
What squash does
Docker's build documentation describes the squash option as experimental and not to be considered stable. Once the image is built, it squashes the new layers into a new image with a single new layer. It does not destroy any existing image, and it creates a new image with the content of the squashed layers. The documentation says this makes it look as if all Dockerfile commands were created with a single layer, and that the cache is preserved.
It also says squashing can help when a Dockerfile produces several layers that modify the same files, for example files created in one step and removed in another. For other cases, squashing may harm performance, for instance when pulling an image made of multiple layers allows parallel downloads.
What a scanner sees
Scanners typically read the final merged filesystem, or the package databases inside it, to list installed software. Squashing does not change that content, other than dropping files deleted in later layers. So a squashed image shows the same installed packages and the same findings as before.
One real effect is on deleted content. If an earlier layer added a file and a later one removed it, the unsquashed image still carries the earlier layer. Squashing drops that data from the image. This can help with the problem of data left behind in layers, though it is not a replacement for keeping secrets out of builds in the first place. See deleted secrets in later layers.
What you lose
| With layers | After squash |
|---|---|
| Findings can be tied to the layer and step that added them | One layer, so attribution is harder |
| Base image layers are shared and cached | Shared layers are lost |
| Easy to see the base image contribution | Base image findings blend with your own |
| Smaller pulls when only top layers change | Whole image changes each time |
Layer attribution is how teams decide whether a fix belongs to the base image owner or the app team. Without it, triage takes longer.
Should you squash?
Usually the better tool for a smaller image is a multi-stage build, which keeps build tools out of the final image on purpose. See multi-stage builds shrink container attack surface. If you do squash, keep the unsquashed image's digest and scan result in your records, and note the base image digest in a label so base image findings remain traceable.
Does it affect SBOMs?
An SBOM built from the final filesystem is the same. An SBOM that records layer information will show fewer layers.
A worked example: before and after
Take a build that installs a compiler, builds a library, then removes the compiler in a later step.
| Step | Unsquashed image | Squashed image |
|---|---|---|
| Install compiler | Layer 2 holds the compiler | Not present |
| Build library | Layer 3 holds the build output | Present once |
| Remove compiler | Layer 4 marks files as deleted, but layer 2 still carries the data | Compiler files are gone from the single layer |
| Final filesystem | No compiler visible | No compiler visible |
A scanner reading the final filesystem reports the same installed packages for both. The difference shows up in size, since the unsquashed image still carries the compiler bytes in layer 2, and in anything that inspects layers, such as a tool that looks for leftovers in earlier layers or a report that attributes findings to a build step.
So squashing can reduce what a layer inspection finds, but it does not change what runs, and it does not remove a vulnerable package that is still installed in the final filesystem.
Step by step: decide whether to squash
- Scan the unsquashed image and keep the result.
- Check the image size and layer count.
- Ask whether a multi-stage build would give the same benefit with clearer intent.
- If you still squash, scan the squashed image and compare package lists. They should match.
- Record the base image digest in a label, because layer based attribution is weaker afterward.
- Keep the unsquashed digest for troubleshooting for a limited time.
What squash does not fix
- A vulnerable package installed in the final image stays vulnerable.
- Data copied into the final filesystem stays there.
- An outdated base image is still outdated.
- A weak runtime configuration, such as running as root, is unchanged.
Treat squash as a size and layer hygiene tool, not as a security control.
What to ask a scanner vendor
- Do you report layer information, and what happens when an image has a single layer?
- Can you identify the base image for a squashed image?
- Do you scan the final filesystem, the layers or both?
If the tool depends on layers to separate base findings from app findings, squashing will blur that separation, and you may want the base digest label to compensate.
Common mistakes
- Squashing to hide findings from a report. The findings are in the filesystem, not the layers.
- Squashing and losing layer sharing between images.
- Relying on an experimental flag in a long lived pipeline without checking current documentation.
Try it yourself
Click through it at your own pace, or open it full screen.
Check that the findings are listed per package, which is what stays the same after a squash.
Where Safeguard fits
Safeguard scans image contents and reports fix versions, so the package list is what you act on. You can try a free scan at gold.safeguard.sh/scan.
Quick check
Will a squashed image have fewer vulnerabilities?
Only if the squash drops files that were deleted in later layers. Installed packages in the final filesystem stay and are still reported.
Is the squash flag stable?
Docker's documentation calls it experimental. Check the current docs before relying on it.
Is a multi-stage build better than squashing?
For most cases, yes. Docker's own documentation says multi-stage builds are usually a better alternative because they give finer control over what ends up in the image.
Sources
Last reviewed: 19 October 2026.
