A container is a stack of layers, and a useful SBOM for that container has to capture each layer's contributions accurately. The naive approach, scanning the final image with a single tool and producing a flat list of packages, misses base image provenance, application-level dependencies, and the language-runtime context that real vulnerability triage requires. This SBOM for containers buyer's guide is for teams who have outgrown the naive approach.
We tested four toolchains against a representative set of 60 container images covering Node, Python, Java, Go, and a few oddballs like Erlang and Elixir. The toolchains were Syft plus Grype, Anchore Enterprise, Trivy with its SBOM mode, and Docker Scout. We measured completeness, accuracy of transitive depth, signing and attestation support, and the operational story around image-to-runtime drift detection.
What does a complete container SBOM actually contain?
A complete container SBOM has three layers of content. The OS layer, package manager entries from apk, deb, or rpm, including the precise version and source repository. The application layer, language-specific dependencies pulled from lockfiles inside the image such as package-lock.json, poetry.lock, go.sum, and pom.xml. And the runtime layer, the interpreter or virtual machine binary itself, which is usually pulled from the base image and is the highest-leverage CVE target in the stack. Most scanners cover the OS layer well, cover the application layer adequately, and are inconsistent on the runtime layer. A scanner that misses the OpenSSL version inside your Node.js base image is missing the most exploited CVE class in the ecosystem.
How do the major tools compare in 2026?
Syft, the open source SBOM generator from Anchore, was the most complete in our test, capturing 96% of expected components across the five language ecosystems. Trivy was a close second at 94%, with marginal gaps in Python's modern packaging metadata. Docker Scout came in at 87%, with strong UX in the Docker ecosystem but weaker depth on transitive dependencies for Java and Go images. Anchore Enterprise, built on Syft, added enterprise features like signed attestations, retention policies, and registry integration. The choice between Syft and Trivy is mostly preference. The choice to use Docker Scout often comes down to whether you have already standardized on Docker tooling and are willing to accept the depth gap. None of them are wrong; they fit different operational shapes.
Why do layered SBOMs matter for vulnerability triage?
When a CVE lands in a base image, you need to know which downstream images inherited the vulnerable component. A flat SBOM tells you the component is present; a layered SBOM tells you which layer introduced it and therefore which rebuild path will remove it. In our test corpus, 71% of CVEs in production images came from base layers, 19% from application dependencies, and 10% from intermediate build layers. The teams that produce layered SBOMs can fix base-layer CVEs by rebuilding from an updated base image in minutes; the teams that produce flat SBOMs are stuck doing dependency archaeology to figure out which Dockerfile to edit. Layer attribution is not optional for any program that scans more than a handful of images.
What is the right story for signing and attestation?
In-toto attestations and Sigstore-signed SBOMs have become table stakes in 2026 for any organization that ships software to customers. The Sigstore project's Cosign and Rekor underpin most of the practical signing tooling, and the SLSA framework provides the conceptual model for what attestations should contain. The realistic implementation is to sign the image, the SBOM, and the provenance attestation at build time, then verify all three at deploy time via policy controllers like Kyverno or admission controllers in your CD pipeline. The operational cost is moderate, mostly key management, and the payoff is large because it closes the supply chain gap where an attacker swaps in a malicious image with a different SBOM. Programs that ship to government or financial-services customers should treat this as a hard requirement.
How do you handle image-to-runtime drift?
A container's SBOM is accurate the moment the image is built and starts diverging the moment a sidecar mutates the filesystem or a runtime installs a package. Drift detection compares the running container's actual contents to the SBOM that was attested at build time. eBPF-based runtime sensors from Falco and several commercial vendors handle this; some lighter-weight approaches use periodic filesystem snapshots. The drift you find is mostly innocuous: log rotation, cache files, certificate updates. But the drift you find is also occasionally a live compromise, and the only way to know is to compare against the signed baseline. Treat drift detection as the audit loop on your SBOM program, not as a separate feature.
How Safeguard Helps
Safeguard ingests container SBOMs with layer attribution preserved, so Griffin AI can attribute each CVE to the specific layer that introduced it and recommend the right rebuild path. Reachability analysis runs against the application code and tells you which container CVEs are actually invoked by your workload, separating real risk from inventory. Policy gates enforce signed SBOM and attestation presence at deploy time, with verification against your trusted Sigstore root. Our zero-CVE base images give you a clean starting layer that eliminates the bulk of base-layer findings before they enter your pipeline. TPRM extends the same model to third-party images you pull from public registries, so you can score the supply chain risk of every base image your developers reach for.