Tern is one of the older SBOM generation tools for containers, predating most of the SPDX and CycloneDX tooling that now dominates the category. It has been overshadowed by Syft in recent years for general-purpose SBOM generation, but Tern has specific strengths that keep it relevant in 2026, particularly around layer-by-layer inspection and the provenance information it captures for OS package installations. For some use cases it remains the better tool.
This walkthrough covers what Tern does well, where it falls short, and how to use it effectively. The audience is teams already familiar with container internals who want to understand whether Tern fits a specific role in their SBOM pipeline.
What does Tern do differently from Syft?
Tern's distinguishing characteristic is that it inspects container images layer by layer, attributing package installations to the specific layer where they were added. Syft inspects the final filesystem view of the image and reports the package set without per-layer attribution. For most consumption use cases, the final SBOM is what matters and Syft is the better tool because it is faster and has broader ecosystem support. For provenance and forensic use cases, Tern's per-layer view is valuable because it tells you which Dockerfile step introduced each package.
The other meaningful difference is Tern's command tracking. When a layer runs apt-get install or pip install, Tern captures the command and the resulting package list, producing a SBOM that includes the install command as provenance metadata. This is useful when you are auditing how a package made its way into the image, particularly in environments where Dockerfile authors are not centralized. Syft can sometimes infer this from layer history but does not capture it as first-class metadata.
How do you install and configure Tern?
Tern is a Python package and installs cleanly via pip in a Python 3.10 or newer environment. The installation also requires Skopeo for image fetching and either Docker or Podman for layer extraction, which can be a friction point in minimal CI runners. The recommended pattern is a dedicated container image with Tern and its dependencies preinstalled, which is what we use in CI. The official Tern image on Docker Hub is updated regularly and avoids the dependency wrangling.
Configuration is minimal for basic usage. The default Tern report includes most of what you want, and the configuration file is only needed when you want to customize the report format, change the output verbosity, or extend the package detection logic. For CI integration, the typical invocation is a single command line that points Tern at the target image and outputs CycloneDX or SPDX format to a specified path. Output generation for a typical image takes 2-6 minutes, which is slower than Syft's 30-60 seconds but acceptable for most pipeline use cases.
How does the layer-by-layer output help?
The layer-by-layer output produces a SBOM where each component is annotated with the layer digest where it was installed and the command that installed it. For a typical multi-stage Dockerfile with a base image, an OS package install layer, and an application install layer, you end up with three groupings of components in the SBOM. This is genuinely useful for several scenarios.
The first scenario is responding to a CVE in a specific package. With per-layer attribution, you can immediately see whether the affected package came from the base image, from an explicit install in your Dockerfile, or from a transitive install. This narrows the remediation path significantly. The second scenario is auditing supply chain risk for a specific install step. If you have a layer that runs pip install from a private mirror, the SBOM tells you exactly what came from that mirror versus the public registry. The third scenario is forensics after an incident, where understanding the introduction point of a malicious package can take hours of manual investigation without per-layer attribution.
What ecosystems does Tern cover well?
Tern's coverage is strongest for the OS package layers: apt, apk, dnf, yum, and the rpm family. The package metadata extraction is reliable, the version capture is accurate, and the license information is included where available. For OS-heavy images, Tern produces high-quality SBOMs.
Coverage is weaker for application-layer ecosystems. Tern can detect pip and npm installs, but the detection is less thorough than Syft's, which has specific parsers for many more ecosystem variants including Go modules, Ruby gems, Maven dependencies, and others. For an image that is heavy in application-layer dependencies, Syft's SBOM will be more complete. A common pattern is to run both tools, use Tern's output for OS packages with per-layer provenance, and use Syft's output for application packages where its broader coverage matters.
How do you integrate Tern into CI?
The CI integration pattern that works is running Tern as a post-build step against the just-built image, with the SBOM output stored as a build artifact and attached as an attestation to the image registry. We use Sigstore Cosign to sign the SBOM with the same key chain we use for image signing, which produces a verifiable provenance trail. The typical CI job adds about 3 minutes to the build pipeline for a moderately sized image.
For pipelines that already run Syft, Tern can be added as a parallel job rather than a sequential one, generating two SBOM outputs that are stored together. The combined storage is small, around 200 KB per image for both SBOMs, and consumers can pick whichever serves their use case. SBOM analysis tools that ingest both formats can correlate them automatically, which is the cleanest pattern when you want the strengths of both.
How Safeguard Helps
Safeguard ingests Tern and Syft SBOMs alongside SBOMs from other generators and unifies them under a single component model. Griffin AI uses Tern's per-layer provenance to attribute CVEs to specific Dockerfile steps, which dramatically speeds up remediation. Reachability analysis runs against the unified SBOM so you see which components are actually used by application code, not just present in some layer. Policy gates can require that every promoted image has both a Tern and Syft SBOM attached, ensuring full coverage of OS and application layers. TPRM data flags components whose suppliers have poor track records, and zero-CVE base images shrink the OS-layer SBOM dramatically, which makes the remaining application-layer findings easier to triage.