Scan an image before you push it by exporting it with docker save, or by pointing a scanner at your local Docker daemon, then checking its packages against vulnerability data. Finding a flaw before the push means it never reaches a registry or a deployment.
Why scan locally first
Once an image is in a registry, other people and systems can pull it. A pipeline may deploy it within minutes. Catching a vulnerable base layer on your laptop is cheaper than catching it after a rollout, and cheaper still than after an incident.
A local scan also covers work in progress. Images that exist only in your Docker daemon cannot be seen by a registry scanner at all.
Export the image
The Docker documentation says docker image save, with the alias docker save, saves one or more images to a tar archive, streamed to standard output by default. The archive includes all parent layers. Examples from that page:
docker save -o myapp.tar myapp:latest
docker save myapp:latest | gzip > myapp_latest.tar.gz
You can limit the archive to one platform with the --platform option, which needs API 1.48 or later. Without it, all platform variants in your daemon's image store are saved. If the platform you ask for is not present locally, the command returns an error.
Check which input your scanner accepts. Some read an archive, some talk to the daemon directly, and some need an image already in a registry. The scanner's documentation is the source of truth.
What a scan should look at
- The operating system packages in the base image.
- Language packages installed by your build, such as those from npm or pip.
- Packages you copied in without a package manager. These are the hardest to detect.
An inventory of all three is a software bill of materials for the image. Match each entry against advisory data, using version ranges as described in the post on OSV introduced and fixed events.
Interpreting results
Expect many findings in a base image, because a base can carry many packages you never call. Do not chase every row. Sort by whether a fix exists, whether the flaw is on a known exploited list, and whether the package is actually used at runtime.
CISA's Known Exploited Vulnerabilities catalog describes itself as the authoritative source of vulnerabilities exploited in the wild, and says organisations should use it as one input to prioritisation. One input, not the whole answer.
Make it a habit
Run the scan in the same step where you build. A tag you never scanned should not be one you push. Rebuild on a schedule too, because new advisories appear for old images.
If the best fix is a newer base image, change the base image and rebuild instead of patching in place, so the result is reproducible.
Where Safeguard fits
Safeguard offers container image scanning and SBOM generation, and Desktop can be used alongside the CLI for local work. Walk through the idea below, or try a manifest at gold.safeguard.sh/scan.
Click through it at your own pace, or open it full screen.
Quick check
Does docker save include all layers?
Yes. The documentation says the archive includes all parent layers.
Is a clean scan proof the image is safe?
No. It means no known advisory matched the packages found. New advisories can appear later.
Sources
Last reviewed: 19 October 2026.
