Usually yes. Scanners work on image content, and Podman, containerd and CRI-O all run images in the OCI or Docker image formats. What changes is how the scanner gets the image: from a registry, from an archive file, or from the local daemon. The first two work regardless of runtime.
Why the runtime matters less than you think
Kubernetes documentation notes that dockershim was removed in release 1.24, and that each node needs a container runtime that works with the Container Runtime Interface. It lists containerd, CRI-O, Docker Engine and Mirantis Container Runtime as common options. So many clusters have no Docker daemon on the nodes at all.
That does not stop image scanning, because the image is the same artifact. A scanner that pulls from the registry sees the same layers whichever runtime later runs them.
Three ways a scanner gets an image
| Route | Needs | Works on non-Docker hosts |
|---|---|---|
| Registry pull | Read access to the registry | Yes |
| Image archive file | A saved tar or OCI directory | Yes |
| Local Docker daemon | A running Docker engine | No |
The registry route is the most portable and is a sound default for CI and scheduled scans.
Saving an image from Podman
Podman's documentation describes podman save as writing an image to a local file or directory, with formats including docker-archive, oci-archive and oci-dir. It notes that the archive preserves the image's layers, history and tags. It also contrasts this with podman export, which flattens a container's filesystem into a single-layer tarball with no image history.
That difference matters for scanning. Save the image, not an exported container, when you want a faithful scan: layers and history help a scanner attribute findings to the step that added them. An exported filesystem can still be scanned for packages, but you lose layer information.
A practical sequence:
- Save the image with podman save in oci-archive format.
- Point your scanner at the archive file.
- Record the image digest alongside the result.
The OCI image layout specification defines the directory structure those archives and directories follow, so a scanner that supports it can read output from different tools.
Questions to ask a vendor
- Can you scan from an OCI archive or directory with no daemon?
- Do you need Docker installed on the machine that runs the scan?
- Can you pull from my registry with a read-only credential?
- Do results record the image digest, not only the tag?
- Do you handle rootless setups, where there may be no shared daemon socket?
Trial test
Take one image, save it with Podman as an OCI archive, and also push it to a test registry. Scan both routes and compare. The package lists and findings should match. If they differ, ask why before you rely on either route.
A worked example: the same image by two routes
A team runs containerd on its nodes and builds images with Podman on laptops. They want to know whether a scanner treats both the same.
Route one: the CI job pushes the image to the registry. The scanner pulls it with a read-only credential, scans it and records the digest.
Route two: a developer runs a save command in OCI archive format and hands the archive file to the scanner on a machine with no container engine.
If the scanner is sound, both runs list the same operating system packages and the same findings, because the layers are identical. The OCI layout specification says an image layout is a directory holding a blobs directory, an oci-layout file and an index.json file, and that it may be carried as an archive, so the two routes carry the same content in different wrappers.
If the results differ, there are a few likely causes: the two routes were different builds, the scanner reads only part of the archive, or the scanner needs the daemon for something and silently skipped it.
Step by step: test a vendor on a host with no Docker
- Pick a test image and build it once. Record the digest.
- Push it to a test registry and save an OCI archive from the same build.
- Run the scanner against the registry reference with a read-only credential.
- Run the scanner against the archive on a machine with no container engine installed.
- Compare package counts and findings between the two results.
- Check that the result states the digest, not just a name.
Rootless and daemonless setups
Some environments run containers without a shared root daemon. A scanner that depends on talking to a daemon socket will not work there, and one that insists on elevated rights may not be allowed. Ask these questions.
- Does it need to run as root?
- Does it need access to a daemon socket?
- Can it run inside a CI job with no extra privileges?
- Can it be told to keep its cache in a given directory?
Kubernetes nodes and scanning
Scanning the nodes' runtime state is a different job from scanning images. Image scanning gives you the content of what you plan to run. Node level tools look at what is installed on hosts. Be clear which one you are buying, and do not expect an image scanner to assess the host or the runtime itself.
Common mistakes
- Exporting a container instead of saving an image, which loses layer history.
- Assuming the scanner needs the same runtime your cluster uses.
- Scanning only on developer laptops and never in CI or in the registry.
- Forgetting multi-architecture images, where each platform may have different content.
Try it yourself
Click through it at your own pace, or open it full screen.
Notice that the report describes image contents and does not mention how the image was run.
Where Safeguard fits
The Safeguard CLI, version 1.4.0, can scan images, and the free scan at gold.safeguard.sh/scan lets you try the idea without installing anything. For no-daemon scanning, see scanning from a tar or OCI layout.
Quick check
Do I need Docker installed to scan an image?
Not if the scanner can pull from a registry or read an image archive. Ask your vendor which routes it supports.
Is podman export good enough for scanning?
It flattens the filesystem and drops history. Prefer podman save so layers and history are preserved.
Does the container runtime on my nodes change scan results?
No. Results depend on image content. The runtime only changes how the image is delivered and run, not what is inside it.
Sources
Last reviewed: 19 October 2026.
