Tern takes a unique approach to container SBOM generation. Instead of just scanning the final filesystem like most tools, it reconstructs the build process by analyzing each image layer independently. The result is an SBOM that tells you not just what is in your container, but how it got there.
How Tern Works
Most SBOM generators treat a container image as a flat filesystem. They look at what packages are installed and report them. Tern does something different. It examines each layer of the container image, attempts to map layers back to Dockerfile instructions, and tracks which packages were added, modified, or removed at each step.
This layer-aware approach has real security value. If a developer installed a build tool in one layer and removed it in the next, the tool's files still exist in the image (just hidden by the overlay filesystem). Tern catches these hidden packages because it analyzes each layer before the overlay.
The tool works by mounting each layer and running package manager queries against it. For Debian-based images, it queries dpkg. For Alpine, it queries apk. For RPM-based images, it checks the RPM database. This approach is thorough but comes with trade-offs that we will get to.
Output Formats
Tern supports SPDX (tag-value and JSON), CycloneDX JSON, and a human-readable report format. The SPDX output is particularly detailed, including file-level entries and package-to-layer relationships that most SBOM generators omit.
The human-readable report is actually useful for debugging. It shows each layer with its associated packages and the Dockerfile command that created it. When you are trying to understand why a particular package ended up in your image, this report format is faster than digging through JSON.
Dockerfile Analysis
Tern's standout feature is its Dockerfile analysis mode. If you provide the Dockerfile alongside the image, Tern maps each layer to the corresponding Dockerfile instruction. This creates a direct link between your build instructions and the resulting packages.
This mapping lets you answer questions like: "Which RUN command introduced the OpenSSL package?" and "What packages come from the base image versus our application layers?" For organizations trying to reduce image bloat or understand their supply chain, this is valuable context.
However, the Dockerfile analysis requires the original Dockerfile. If you are analyzing third-party images or images from a registry where the Dockerfile is not available, you lose this feature.
Performance Considerations
This is where Tern falls behind competitors. Because it mounts and analyzes each layer independently, scan times are significantly longer than tools like Syft or Trivy. A moderately complex image with 15-20 layers can take 2-5 minutes to analyze, compared to 5-15 seconds with Syft.
The layer mounting approach also requires root privileges or specific filesystem capabilities. Running Tern in a CI pipeline means either running as root (security concern), using a privileged container (same concern), or configuring rootless mode (which requires additional setup).
For ad-hoc analysis and deep inspection, the performance trade-off is acceptable. For CI pipeline integration where every second counts, Tern is harder to justify.
Accuracy and Coverage
Tern excels at OS-level package detection. Its approach of querying the actual package manager database is more reliable than file pattern matching. If dpkg says a package is installed, it is installed. There is no guesswork.
Application-level dependency detection is weaker. Tern does not natively parse npm lock files, Python requirements, or Java manifests. It can detect some application packages through extensions, but the coverage does not match Syft or Trivy. If your containers include significant application-level dependencies (which most do), Tern gives you an incomplete picture.
This limitation is architectural. Tern's layer-by-layer analysis works well for packages managed by OS package managers because those managers maintain state databases. Application package managers do not always leave the same kind of queryable state in the filesystem.
Extension System
Tern has an extension system that allows adding new analysis capabilities. Extensions can add support for new package managers, output formats, or analysis techniques. The Scancode extension, for example, adds license detection using the ScanCode toolkit.
In practice, the extension ecosystem is small. The core team maintains a few extensions, but community contributions have been limited. This is a reflection of Tern's smaller user base compared to Syft or Trivy.
Where Tern Fits
Tern is best used as a complementary tool rather than a primary SBOM generator. Its layer analysis provides insights that other tools miss, but its limited application dependency coverage means it should not be your only SBOM source.
A solid workflow: use Syft for your primary SBOM generation (covering both OS and application dependencies), and use Tern for periodic deep inspections of critical images where layer provenance matters.
Tern is also valuable for compliance scenarios where regulators want to understand the full composition of a container image, including packages in hidden layers. The SPDX output with file-level detail satisfies the most demanding compliance requirements.
Project Health
Tern is maintained by the VMware open source team and hosted under the Linux Foundation. Development has slowed compared to its peak in 2020-2021. Issues and PRs still get attention, but the release cadence is not as aggressive as Syft's.
The project's focus on SPDX compliance and layer analysis gives it a specific niche. It is not trying to compete with Syft or Trivy on breadth. Whether that focus will sustain the project long-term depends on how much the market values layer-aware SBOM generation.
How Safeguard.sh Helps
Safeguard.sh can ingest SBOMs from Tern alongside SBOMs from other generators, merging the layer-aware data from Tern with the application dependency data from tools like Syft. This gives you the most complete picture of your container composition without having to manually reconcile multiple SBOM documents. Safeguard.sh normalizes the different levels of detail into a unified component inventory, so your security team sees one consistent view regardless of which tools generated the underlying data.