Container image scanning
dpndncY parses an OCI image tarball server-side, walks every layer, and produces a per-layer SBOM of OS and language packages — then correlates them against the same vulnerability + exploit-signal stack as source scanning. No daemon access required; it reads the saved tarball.
What it inspects
The OCI parser unpacks the image manifest and config, then walks each filesystem layer to recover:
- OS packages — Debian/Ubuntu (dpkg), Alpine (apk), RHEL/Rocky (rpm).
- Language packages baked into the image — npm, PyPI, Go, RubyGems, PHP/Composer, .NET — 9 in-image ecosystems in total.
- Layer attribution — every component is mapped to the layer (and therefore the Dockerfile instruction) that introduced it, so you know whether to fix the base image or your build.
Scan an image
CLI
# save the image to a tarball, then scan it
docker save my-app:latest -o my-app.tar
dpndncy scan my-app.tar --type image
# or scan straight from a registry (server pulls the manifest)
dpndncy container scan registry.example.com/my-app:latestFix the lowest layer that owns the vuln
Because findings are layer-attributed, a vulnerability in the base OS layer is a base-image bump, while one in your
pip install layer is a dependency fix. dpndncY tells you which.Distroless, scratch & multi-arch
- Distroless / scratch — no OS package DB, so dpndncY relies on the language-package and signature detectors for whatever is copied in.
- Multi-arch — point the scanner at the specific platform manifest you ship.
Output
- Per-layer SBOM (CycloneDX / SPDX).
- Findings with layer attribution, base-image upgrade guidance, and the full signal stack (KEV/EPSS/ExploitDB).
See also
- Signature / binary scan — for statically-linked binaries inside the image
- SCA — the same correlation stack