When a base image strips out its package manager, shell, and OS metadata, most vulnerability scanners lose their footing. Distroless and other hardened, minimal images are increasingly the default for security-conscious teams — smaller attack surface, fewer binaries an attacker can live off of, faster pulls. But that same minimalism removes the /var/lib/dpkg or /var/lib/rpm databases that traditional composition-analysis tools query to figure out what's actually installed. The result: scanners built around package-manager metadata either report an image as "clean" because they can't see inside it, or they fall back to shallow layer-hash matching that misses transitive dependencies entirely.
This matters because hardened images are exactly the ones organizations trust most — which makes a false sense of security in that scanning layer especially costly. Below, we look at how Safeguard approaches deep visibility into distroless and minimal images, and how that compares to Black Duck's composition-analysis heritage.
Why Do Distroless and Hardened Images Break Traditional Scanning?
Distroless images (the pattern popularized by Google's gcr.io/distroless project, and now mirrored by Chainguard's Wolfi-based images, Red Hat's UBI-micro, and various in-house "scratch-plus-binary" builds) deliberately omit the components that conventional scanners depend on: a package manager, a shell, and the OS-level manifest files that record what's installed. That's the entire point — less installed means less to exploit.
The problem is that many scanning tools originated in a world of full-fat OS images, where reading dpkg status or rpm -qa output was a reliable, cheap way to enumerate packages. Strip that manifest out, and a manifest-dependent scanner has two options: report nothing (a dangerous false negative), or fall back to matching known base-image layer hashes against a database of "known good/known bad" layers — which breaks the moment a team rebuilds, patches, or customizes that base layer even slightly.
Getting real visibility into a distroless image means walking the actual filesystem: identifying binaries by content rather than by manifest entry, matching statically linked language runtimes (Go binaries, Rust binaries, musl-based builds), and reconstructing a software bill of materials from what's physically present in the layers — not from what a package database claims is present.
What Is Black Duck Built to Detect, and Where Does That Heritage Show Up?
Black Duck's product lineage traces back to Black Duck Software, founded in 2002 around software composition analysis (SCA) and open-source license compliance — helping legal and engineering teams answer "what open-source code is in this codebase, and what license obligations come with it." Synopsys acquired Black Duck in 2017 and built out its container and container-registry scanning on top of that same KnowledgeBase-driven SCA engine; Black Duck was later spun back out as an independent company in 2024.
That heritage is a genuine strength for source-tree and dependency-manifest analysis — lockfiles, package.json, pom.xml, and similar declared-dependency formats are exactly the kind of structured input an SCA KnowledgeBase excels at correlating with known vulnerabilities and license terms. It's a different problem, however, from identifying what's actually running inside a hardened container layer once you're past manifests and into raw binaries. Organizations evaluating any composition-analysis-rooted tool for distroless coverage should ask directly how it identifies OS-level and statically linked components when no package manager or manifest is present — that's the question that separates SCA-for-source-code from purpose-built container filesystem scanning.
How Does Safeguard Achieve Deep Visibility Into Minimal Images?
Safeguard's container scanning is built filesystem-first, not manifest-first. Instead of assuming a package database exists, Safeguard walks every layer of the image and:
- Fingerprints binaries by content, not by package-manager record, so statically compiled or vendored libraries inside a stripped image are still identified.
- Detects language-runtime dependencies embedded in compiled artifacts — for example, module and version strings baked into Go binaries, or dependency metadata embedded in Rust and Java artifacts — which matters because distroless application images are frequently Go or JVM services with no OS package manager at all.
- Analyzes each layer independently, so a vulnerability introduced in a base layer is still attributed correctly even if a later layer rebuilds or shadows part of the filesystem.
- Generates an SBOM from what's observed on disk, in CycloneDX and SPDX formats, so the bill of materials reflects the image as built rather than the image as declared.
This is deliberately a lower-level approach than manifest parsing. It costs more engineering to build and maintain (binary fingerprint databases have to track many more identification patterns than package-manager records do), but it's what's required to say with confidence that a distroless image was actually scanned rather than skipped.
SBOM Accuracy: Package-Manager Metadata vs. Binary-Level Fingerprinting
The clearest, most testable difference between these two approaches is what happens to SBOM completeness when you point a scanner at a genuinely minimal image. A manifest-driven SBOM generator run against a distroless image will typically produce a very short component list — because there's very little package-manager metadata to read — even though the image may contain a full application runtime, several transitive libraries, and OS-level shared libraries copied in during a multi-stage build.
You can verify this yourself in about ten minutes: pull a distroless/base or Chainguard image, run it through whatever scanner you currently use, and compare the resulting SBOM's component count against docker run --rm -it --entrypoint sh <image> style inspection (where the image allows a shell) or a docker export | tar -t layer listing. If the SBOM is dramatically shorter than what the filesystem actually contains, that's a manifest-dependency gap, not a "clean image."
Safeguard's binary-level fingerprinting is designed to close that specific gap — the SBOM reflects filesystem contents, and vulnerability matching runs against that reconstructed component list rather than a package-manager query that returns nothing.
Which Approach Scales for CI/CD Pipelines Running Hardened Base Images?
Hardened base images are usually adopted precisely because a team is trying to reduce operational and security overhead — smaller images pull faster, patch faster, and give attackers less to work with post-compromise. A scanning step that silently degrades to "no findings" on exactly those images undermines that goal at the point it matters most: the CI/CD gate that's supposed to catch a regression before it reaches production.
Two concrete, checkable things to look for when evaluating scanners for a hardened-image pipeline:
- Does scan output visibly report package/component counts, or just a pass/fail? A scanner that surfaces "0 components identified" alongside "0 vulnerabilities found" is telling you it couldn't see inside the image — that distinction should be visible in your pipeline logs, not hidden behind a green checkmark.
- Does the tool re-scan and re-attribute correctly after a base-image rebuild? Layer-hash-matching approaches can lose track of an image the moment the base is rebuilt with a new hash, even if the actual contents and vulnerability profile are unchanged. Filesystem-content-based scanning re-identifies components regardless of layer hash.
Both are things you can test directly against your own images rather than take on faith from any vendor, Safeguard included.
How Safeguard Helps
Safeguard treats distroless and hardened images as a first-class scanning target, not an edge case handled by a fallback path. In practice, that means:
- Filesystem-first scanning that doesn't require a package manager, shell, or manifest to identify what's installed — binaries are fingerprinted directly, so
distroless, Wolfi-based, UBI-micro, and scratch-based images all get full coverage rather than a truncated component list. - SBOM generation that reflects actual image contents, exported as CycloneDX or SPDX, so downstream compliance and audit workflows aren't working from an incomplete inventory.
- Layer-attributed findings, so a vulnerability introduced in a shared base layer is traceable to that layer even across teams building on top of it independently.
- CI/CD-native gating that reports component counts alongside vulnerability counts, so a scan that finds "nothing" because it couldn't see inside the image is visibly distinguishable from a scan that found nothing because the image is genuinely clean.
- Continuous re-scanning tied to registry pushes, so a hardened base image's security posture is re-evaluated on every rebuild rather than relying on a cached, hash-based judgment that goes stale.
If your organization has standardized on distroless or other minimal base images and you're not confident your current scanner is actually seeing inside them, that's a testable question, not a matter of trust — run the ten-minute comparison above against your own registry and see what comes back. Safeguard's container scanning is built for exactly this class of image, and we'd rather you verify that with your own images than take our word for it.