Distroless and Wolfi-style minimal container images are popular precisely because they strip out the shells, package managers, and OS cruft that traditional vulnerability scanners depend on. That creates a real problem: a scanner that reads /var/lib/dpkg/status or queries apk info for a package list finds nothing to read in a distroless image, because that database was never installed. Google's distroless images, Chainguard's Wolfi-based images, and similar "minimal" bases have become default choices for production workloads specifically to shrink attack surface — but they force scanners to change how they identify what's actually inside a layer. Snyk Container is one of the more widely documented tools that adapted to this shift. This post walks through the publicly documented mechanics of how it approaches distroless and minimal images, where those techniques still fall short, and what that means for teams trying to keep an accurate vulnerability picture across a fleet of hardened images.
Why do distroless and Wolfi-style images break traditional container scanning?
They break it because the metadata scanners normally read to build a package inventory simply isn't present. A standard Ubuntu or Debian image carries a dpkg status file listing every installed package, its version, and its source; Alpine carries an apk database at /lib/apk/db/installed; RPM-based images carry the rpm database under /var/lib/rpm. Distroless images, by design, remove the package manager binary and, in most variants, its metadata database along with it — Google's gcr.io/distroless/* family, for example, ships only the language runtime and application layer needed to run a binary, with no shell and no apk/dpkg tooling at all. Wolfi-based images from Chainguard take a related but distinct approach: they're built with the apk package format for reproducibility and SBOM generation, but the resulting runtime images are still deliberately pared down, often to just glibc, a handful of shared libraries, and the application. A scanner built around "run a package manager command and parse the output" has nothing to invoke in either case, which is why distroless support required Snyk to build a separate detection path rather than extend the existing one.
How does Snyk Container identify OS packages when there's no package manager database?
It identifies them by fingerprinting files inside each image layer instead of querying a package database. Snyk publicly documented adding distroless scanning support around 2020–2021 for the gcr.io/distroless image family, describing a static-analysis technique that extracts files from every layer and computes signatures for binaries and libraries, then matches those signatures against a reference index built from known upstream OS packages (Debian and its derivatives, in the case of Google's distroless base). Because Snyk already maintains vulnerability data mapped to specific package versions for those same distributions, matching a file fingerprint to a known package build effectively reconstructs the "installed package list" that would otherwise have come from dpkg or apk metadata — without ever needing a package manager to be present in the target image. This is why Snyk's own documentation is explicit that distroless support is scoped to the base image families it has indexed this way, rather than being a general capability that works against any minimal image out of the box.
Which minimal and distroless image families does Snyk actually support?
Support is scoped to a specific, named list rather than "any small image." Snyk's documentation enumerates the Google distroless variants it supports — including distroless/base, distroless/cc, distroless/java, distroless/nodejs, distroless/python, and distroless/static — reflecting the fact that its fingerprint index has to be built and maintained per base-image family. Chainguard's Wolfi-based and "chainguard-images" catalog images are handled differently in practice: because many Wolfi-derived images still carry an apk database (Wolfi is built as an apk-compatible package set, even when the runtime image is trimmed), Snyk can in a number of cases fall back to its standard apk-based OS scanning path rather than needing pure file fingerprinting. Coverage for any given base image ultimately depends on whether Snyk has built and shipped a detection path for it, which is why teams standardizing on a less common minimal base should verify support against Snyk's current documentation rather than assume parity with the Google distroless family.
Does Snyk still scan language-level dependencies inside these images the same way?
Yes — the fingerprinting approach is specific to OS-level packages, and application dependency scanning works largely as it does elsewhere. Language ecosystem manifests and lockfiles (a package-lock.json, a Python requirements.txt-derived install, a compiled Go binary's embedded module list, a Java pom.xml-driven dependency tree) are extracted from the relevant layer and matched against Snyk's language vulnerability database the same way they would be for a full Ubuntu-based image, since that detection was never dependent on the OS package manager in the first place. In practice this means a distroless Node.js or Python image gets two parallel detection paths inside a single scan: OS libraries identified through file fingerprinting, and application-level packages identified through the ecosystem's own manifest or installed-package layout. This is a meaningful distinction for anyone doing a report review, since "no OS vulnerabilities found" in a distroless scan can mean either that the base image is genuinely clean or that the fingerprint index didn't recognize a customized file — the confidence level differs from a standard OS scan where a package database was directly readable.
What role do SBOMs play in scanning Wolfi and Chainguard-style images?
SBOMs increasingly serve as a second, complementary path for identifying packages in minimal images, alongside direct image scanning. Chainguard publishes SBOM attestations (typically in SPDX or CycloneDX format, signed via Sigstore/cosign) alongside its images as part of its supply-chain security model, and Wolfi's build system is designed to produce accurate, reproducible package manifests as a first-class output rather than an afterthought. A scanner that can ingest that SBOM directly gets an authoritative package list without needing to fingerprint files at all, which sidesteps the coverage gaps inherent in file-matching against an index that may not include every custom or rebuilt package. This is a broader industry direction, not a claim specific to any one vendor's roadmap: as more minimal-image publishers ship verifiable SBOMs by default, scanning tools generally are shifting toward "consume the attestation when it's trustworthy, fall back to binary analysis when it isn't" rather than relying on file fingerprinting as the only option for hardened images.
What are the limitations of fingerprint-based detection for distroless images?
The main limitation is that fingerprinting can only recognize what it has already indexed, so it degrades on anything customized. If a team builds a custom distroless image by copying in a self-compiled binary, patches a library and rebuilds it, or uses a base image family Snyk hasn't built a fingerprint index for, the technique has no package database to fall back on and can under-report or miss vulnerabilities entirely — a materially different failure mode than a standard scan, where an unparseable package database at least throws a visible error. There's also a maintenance burden on the vendor side: every new distroless base image version needs its fingerprint index rebuilt to stay current, which is part of why Snyk's supported list is a fixed, named set rather than "all distroless images." Teams relying on distroless or Wolfi-based images in production should treat scanner coverage of these bases as a question to verify explicitly — checking a vendor's current supported-image documentation and, where possible, cross-referencing against the image publisher's own SBOM — rather than assuming a scanner that works well on Ubuntu-based images will behave identically on a minimal one.
How Safeguard Helps
Minimal and distroless base images are becoming the default for security-conscious teams, which means an accurate vulnerability and SBOM picture for these images matters more every quarter, not less. Safeguard's platform is built around ingesting and correlating SBOMs — including those published directly by image maintainers like Chainguard — against a continuously enriched vulnerability database, so a package identified via attestation or via layer analysis lands in the same view as everything else in your software supply chain, rather than in a separate report you have to reconcile by hand. Because coverage gaps for hardened images tend to hide in the fine print of "which base image families are actually supported," Safeguard's scanning pipeline is designed to combine SBOM ingestion with direct image and dependency analysis, giving teams a way to see where a given base image's package inventory came from and how confident that inventory actually is. For organizations standardizing on distroless or Wolfi-based images as part of a broader hardening effort, that visibility — plus policy controls to gate builds on SBOM presence and vulnerability thresholds before they reach production — is what turns "we adopted minimal images" into a verifiable security outcome instead of an assumption.