Docker Image Inspector (Layers & Vulnerability Scan)
Every layer, wasted byte, package and known vulnerability of a container image.
Try before you buy.
- Free preview: the image config and history, every layer’s sizes, the efficiency score and the number of vulnerable packages, with the first rows (up to 10) of each list.
- Locked until you unlock it: download and copy.
- Unlock: Pro pass, ₹179 for 30 days or ₹79 for 1 week, a one-time payment that never renews. Unlock: Pro pass, $5.99 for 30 days or $2.99 for 1 week, a one-time payment that never renews.
Ways to unlock shows how to get the full result.
Printing this result is locked in the free preview.
Make one from an image
docker save -o image.tar nginx:1.27 podman save -o image.tar nginx:1.27 skopeo copy docker://nginx:1.27 oci-archive:image.tar
Image
Locked in the free preview. Opens the ways to unlock this result.
Locked in the free preview. Batch runs unlock with a pass.
Locked in the free preview. Query results unlock with a pass.
About the Docker Image Inspector (Layers & Vulnerability Scan)
Open the tar archive of docker save or podman save, or an OCI image layout as a tar — plain, gzip or zstd compressed, up to 4 GB — and see what the image really holds: its config (entrypoint, command, user, ports, labels and the environment, with secret-looking values masked), the build history, every layer with its size and files, the image's largest files, and the wasted space: bytes a later layer overwrote or deleted that are still downloaded with every pull, with an efficiency score.
The OS packages are read from the package manager's own database (apk on Alpine and Wolfi, dpkg on Debian and Ubuntu, RPM on Rocky Linux, AlmaLinux and other newer Red Hat family images), with the language packages installed or locked in the image (npm, Python, Ruby gems, Composer and lockfiles). Check against OSV.dev asks the open vulnerability database about them and lists every advisory with its severity and the version that fixes it. The findings name what to fix: running as root, secrets in the environment, labels, build arguments and files — also in files a later layer deleted — a .git folder, caches and setuid programs. Two images can be compared.
The archive is read in your browser as a stream and never uploaded; only package names and versions go to OSV.dev, when you ask. Without a pass the result is a free preview: the config and history, every layer's size, the efficiency score and the number of vulnerable packages, with the first rows of each list; every row, the comparison and the Markdown, JSON and CSV reports unlock with a Pro pass.
How to use it
- Save the image as an archive:
docker save -o image.tar nginx:1.27(orpodman save, orskopeo copy docker://nginx:1.27 oci-archive:image.tar). - Open the .tar here (drag it onto the page or choose it). Large images are read in pieces with a progress bar; nothing is uploaded.
- Go through the tabs: Config, Layers (with each layer’s files), Files, Wasted space, Packages, Vulnerabilities, Findings and Compare.
- Choose Check against OSV.dev to look up known vulnerabilities; only package names and versions are sent.
- With a pass, copy or download the report as Markdown, JSON or the vulnerabilities as CSV; the free preview shows the first rows of each list.
Examples
COPY . /app (with a .env file), then RUN rm /app/.env
Findings: the password in /app/.env is still in layer 3 — the later layer only hides it — with the secret masked
Anyone who pulls the image can read every layer. Keep secrets out of the build context with .dockerignore.
RUN apt-get update && apt-get install -y build-essential, then RUN rm -rf /var/lib/apt/lists/*
Wasted space: /var/lib/apt/lists still takes its full size in the earlier layer; efficiency below 100%
Clean up in the same RUN step that made the files.
Alpine 3.19 with openssl 3.1.4-r1
Vulnerabilities: the advisories OSV.dev lists for openssl on Alpine v3.19, each with the fixed version
Common uses
- Finding out why an image is so large, layer by layer, before trimming its Dockerfile.
- Checking a third-party or vendor image for known vulnerabilities and leaked secrets before running it.
- Comparing an image before and after a change: config, layers, files and package versions.
- Reviewing what a build really put into an image when you cannot run Docker on the machine you are using.
What the archive holds
docker save and podman save write a tar with a manifest.json, the image config (JSON) and one tar per layer; newer Docker versions lay it out as an OCI image layout, with blobs named by their SHA-256 digest and an index.json (OCI image layout). Layers may be plain tar, gzip or zstd (OCI layer media types). A multi-platform index can list platforms whose layers are not in the archive; the page says how many.
How the layers stack, and what "wasted" means
A container sees the layers stacked in order: a later layer can add files, replace them, or delete them with a whiteout file (.wh.<name>, or .wh..wh..opq for a whole folder). A file that is replaced or deleted is still inside its own layer, so it is downloaded and stored with every copy of the image though no container can see it — that is wasted space. The efficiency score is the share of all file bytes in the layers that a container still sees. Remove temporary files in the same RUN step that made them, or build in stages and copy only the result.
Packages and vulnerabilities
OS packages come from the package manager’s database in the image: apk’s /lib/apk/db/installed, dpkg’s /var/lib/dpkg/status (and the status.d of distroless images) and RPM’s rpmdb.sqlite. Language packages come from node_modules, Python’s .dist-info metadata, gem specifications, Composer’s installed.json and lockfiles. OSV.dev is asked about each package in its ecosystem — for Alpine and Debian by source package, as their advisories are written (OSV schema) — and every advisory is listed with its CVSS v3 score when it has one and the version that fixes it.
Secrets in images
Environment variables, labels and the build history are part of the image config, which anyone who can pull the image can read; build arguments are written into the history in plain text. The findings use the rules of the Secret Scanner (gitleaks-compatible) on the config, the history and likely secret files of every layer, and only ever show secrets masked. A secret found in an image should be rotated: removing it from the next build does not remove it from images already pushed.
Limitations
- Images up to 4 GB. Each package database and lockfile is read up to its size limit (256 MB for package databases), and likely secret files up to 256 KB each.
- Older RPM databases (Berkeley DB, as in CentOS 7 and 8, RHEL 7 and 8 and Amazon Linux 2) and SUSE’s are not read yet, and Red Hat Enterprise Linux packages are not checked: OSV.dev keys Red Hat advisories by product and repository.
- Distributions without data in OSV.dev (Fedora, Amazon Linux, CentOS) have their packages listed but not checked.
- Programs built into a single binary (Go, Rust) and Java archives are not opened, so the libraries inside them are not listed.
- Files are compared by size, type, permissions and link target, not by content.
Privacy
Sends data to online services
The image is read in your browser and never uploaded. Only when you check for vulnerabilities, the ecosystem, name and version of each package found are sent to OSV.dev (the open vulnerability database), with no cookies; nothing goes through MySmartCoPilot.
Frequently asked questions
What do I get without a pass?
Without a pass, Docker Image Inspector (Layers & Vulnerability Scan) shows the image config and history, every layer’s sizes, the efficiency score and the number of vulnerable packages, with the first rows (up to 10) of each list. Until you unlock it, the result can’t be downloaded or copied. A Pro, Premium or Ultimate pass, a one-time payment that never renews, unlocks the full result. The pricing page lists the passes and their prices.
Is my image uploaded?
No. The archive is read in your browser, in pieces, and never leaves your device. The only request is the vulnerability check, when you ask for it: it sends each package’s ecosystem, name and version to OSV.dev, with no cookies, and nothing about your files.
How do I get an image archive from a registry without Docker?
With skopeo: skopeo copy docker://registry.example.com/team/app:1.0 oci-archive:app.tar, or crane pull registry.example.com/team/app:1.0 app.tar. Both write an archive this page opens.
Why does the vulnerability list differ from my registry’s scanner?
Scanners use different databases and rules: some read vendor advisories this page does not (Red Hat), some open binaries to find bundled libraries, and some hide advisories the distribution marks as not affecting it. This page lists what OSV.dev says for the exact versions installed.
Why is a deleted file still counted?
Because it is still in the image. Each layer is an archive of its own; a later layer can only hide a file, not take it out of the earlier layer. Delete it in the same step that created it, or use a multi-stage build.
Which image formats can it open?
The tar archives of docker save and podman save (the classic layout and the newer OCI layout), and OCI image layouts packed as a tar, including multi-platform indexes; the archive and its layers may be gzip or zstd compressed.