A distroless image SBOM is shorter, because the image holds your application and its runtime dependencies and little else. But a scanner that learns about packages from a package manager database may find less than you expect. Test one image, and add a build time SBOM so nothing is lost.
What distroless means
The distroless project describes these images as containing only your application and its runtime dependencies, and says they do not contain package managers, shells or other programs you would expect in a standard Linux distribution. Its stated reason is to restrict what is in your runtime container to what your application needs.
For an SBOM that has two effects. The component list should be shorter, which is the point. And the usual places a scanner looks for installed software may be sparser, so you need to check how your tool recognises what is inside.
How scanners learn what is in an image
| Evidence source | Present in a full distribution image | Present in a minimal image |
|---|---|---|
| Package manager database | Yes | Depends on how the image was built |
| Language lockfiles or metadata inside the app layer | If copied | If copied |
| Compiled binaries with embedded build information | Yes | Yes |
| Shell and common utilities | Yes | No |
The first row is the one to check. Where the image has no package database, a scanner may fall back to inspecting files and binaries, which can identify fewer components or give lower confidence results. I would not assume either outcome. Test it on your own image.
A check you can run
- Build your application on a standard base image and on a distroless or minimal one.
- Generate an SBOM for each from the final image.
- List components by type: operating system packages, language packages, and unclassified files.
- Note what appears in one and not in the other.
- Compare against what you know the runtime needs, such as the C library and certificates.
If the minimal image reports almost nothing at the operating system level, ask whether that is because it contains almost nothing, or because the tool could not see it.
Close the gap at build time
A build time SBOM is generated while the image is made, when the builder knows what it installed. Docker's documentation notes that indexing contents during the build has benefits over scanning a final image, since you can detect software used to build it that might not show up in the final image. For minimal images, that build record can be the more complete source of truth for the layers you assembled. Record the base image digest too, so a reader can trace it.
What to say to a customer
Tell them the image is minimal by design and what scope your SBOM covers. A short note such as "runtime image, no shell or package manager, SBOM generated at build time and from the final image" prevents the question of whether an empty looking SBOM is hiding something.
Try it yourself
Click through it at your own pace, or open it full screen. Compare how many findings come from the base layers and how many from application packages.
Where Safeguard fits
Safeguard scans container images and produces SBOM output, with reachability analysis for application dependencies. Try your own minimal image with the free scan at gold.safeguard.sh/scan.
Quick check
Does a smaller image mean a smaller attack surface?
Generally fewer components means fewer things to patch, but it still needs verifying. Scan the image you actually ship.
Why might my scanner find little in a minimal image?
Either there is little there, or the tool lacks the package metadata it relies on. Compare with a build time SBOM.
Sources
Last reviewed: 19 October 2026.
