The Best SBOM Tools in 2026: 18 Tools Compared by What They Read

On July 29, 2026, CISA and seventeen partner agencies replaced the 2021 NTIA minimum elements for a software bill of materials. Ten data fields are new, the element governing dependency depth was rewritten, and one accepted format was removed outright.

Most published guidance on SBOM tools still measures them against the version it replaced. There is a second gap and it is wider: across the major published comparisons, eighteen tools get named and not one of them reads a shipped firmware image.

Finite State publishes this page and appears on this list. The order below is by scan target, starting with tools that read compiled artifacts, which is why we are first rather than because we rate ourselves highest. If your software ships from a repository in a supported language, start at entry three. Every capability claim about every tool is sourced to that tool's own documentation.

If you want the underlying concepts first, our practical guide to SBOMs and software supply chain security covers formats, depth, and VEX before you start comparing products.

How to Evaluate an SBOM Tool

Five criteria, each checkable against a tool's documentation rather than its marketing. Three of them only became checkable on July 29, 2026, when CISA and seventeen partner agencies replaced the 2021 baseline. What changed is covered in full after the list.

1. Scan target. A manifest, a source tree, a container image, a registry artifact, or a shipped binary. A generator pointed at a manifest records what the build intended to include. One pointed at a compiled artifact records what came out. Those two documents disagree more often than most teams expect, and the disagreement concentrates in the components you did not write.

2. Reachability method and its prerequisites. Not whether a vendor claims it, but what it requires as input and which languages it covers.

3. Which lifecycle phase it can declare. Before build, build, or after build. Now a required field rather than an implementation detail.

4. Whether it can hash what it describes. Component Hash Value is computed over an executable component artifact, so a tool that never touches one must record the value as unknown.

5. Honesty about gaps. Whether the tool distinguishes what it could not determine from what was deliberately left out. A generator that silently omits what it could not resolve produces a document that looks complete and is not.

The table below covers all eighteen tools named across the major published comparisons. Ten are examined in detail afterward.

The table above is unordered. The ten numbered entries that follow cover eleven of those tools, grouped by scan target. Entries 1 and 2 read compiled artifacts. Entries 3 through 8 read builds, source trees, and container images, which is where most of the category lives and where most readers will correctly end up. Entry 9, Dependency-Track, consumes SBOMs rather than generating them, and entry 10, FOSSA, generates from manifests and source with license compliance as its focus.

1. Finite State

Entries 1 and 2 take a compiled artifact as input, and that is a much smaller group than the category's marketing suggests.

What it reads. Shipped firmware images and compiled binaries, no source or supplier cooperation required. Around ninety unpacker plugins cover SquashFS, UBI and UBIFS, JFFS2, CramFS, RomFS, and ext2 through ext4.

[VERIFY: pending Jermaine's answer on source-code dependency SCA. Our own platform page and docs both state SBOM generation from source as well as binaries, so this line is incomplete as written.]

Where it is strong. SBOMs are generated after build, from the shipped binary, which is what lets every resolvable component carry a SHA-256 hash. Exports are CycloneDX 1.6 and SPDX 2.3, in both directions, with or without vulnerabilities. The dependency graph is nested with no configured depth limit, and the same component at two versions in one image stays two entries. Licenses are populated and normalised to SPDX identifiers.

CycloneDX output carries inline VEX, and the analysis behind it is machine-derived rather than hand-entered. Findings whose reachability comes back negative can be written as not affected, with a justification of code not reachable, on a customer-triggered run.

Where it stops. Statically linked components have no separate artifact to hash, so they carry none. Per-component file paths exist in the platform but are not carried into the export, so a consumer sees two instances of a library without knowing which is which. VEX is emitted inside the SBOM in CycloneDX only, not standalone, and not in CSAF or OpenVEX.

Best fit. Device manufacturers with supplier binaries in the image and a filing deadline. Skip it if your software never leaves the repository. The method is covered in more depth under binary software composition analysis, and the generation, ingest and lifecycle side sits on the Finite State platform page. If you want to see what a firmware image of your own reports, request a demo.

2. Black Duck Binary Analysis

Binary SBOM generation gets described as a niche that nobody serves. The technology behind Black Duck's has been in the market since 2015, when Synopsys acquired Protecode.

What it reads. Compiled artifacts with no source code required, covering executables, libraries, containers, and embedded system firmware, across a broad range of CPU architectures.

Where it is strong. BDBA combines static and string analysis with fuzzy matching against the Black Duck KnowledgeBase, and identifies components even when they have been modified, which is the hard part of reading a binary. Available as a cloud service or an on-premises appliance. The license compliance engine behind it is among the deepest in the category and turns up routinely in M&A due diligence.

Worth crediting directly: Black Duck's own documentation makes the case that checking the compiled product against a source scan reveals what the shipping product actually contains. That argument is stronger coming from them than from us.

The lineage is worth getting right, because published comparisons routinely do not. Synopsys acquired Protecode in November 2015 and Black Duck Software in 2017, then folded the Protecode product under the Black Duck brand as Black Duck Binary Analysis. The combined business was spun out on October 1, 2024, when Clearlake Capital and Francisco Partners completed their acquisition of the Synopsys Software Integrity Group. Black Duck has been independent since, and it is not a Synopsys product.

Where it stops. Source scanning and BDBA are two products rather than one workflow. Deployment and configuration complexity is the consistent criticism across third-party reviews.

The verdict. If you need binary SBOM generation inside a broad enterprise application security programme, this is the mature answer and the closest thing here to a direct alternative to number one.

3. Syft

Entries 3 through 8 read builds, source trees, and container images. This is where most of the category lives.

What it reads. Container images, filesystems, and archives, covering OCI, Docker, and Singularity formats. Syft also detects the Linux distribution in use, which gives OS-level packages proper context rather than listing them loose.

Where it is strong. Output in SPDX, CycloneDX, and its own JSON, so it fits whatever the downstream consumer expects, and it will convert between formats after the fact rather than forcing a rescan. Clean CLI, strong CI/CD integration, and an active Anchore-backed community that keeps ecosystem coverage current as new package managers appear.

It pairs directly with Grype, which takes a Syft SBOM as input, so generation and scanning separate cleanly across teams or stages. That separation is more useful than it first looks: the expensive step runs once, and the cheap step reruns whenever the vulnerability data changes.

Where it stops. Syft generates and stops there. It is not a repository, so comparing SBOMs across releases or monitoring them over time needs something else underneath. Kusari's testing reports that its speed sometimes comes at the cost of dependencies other tools find.

Best fit. Teams that want a dependable, scriptable generator in the pipeline and already have somewhere to put the output.

4. Trivy

One binary that generates the SBOM and scans it, which is why Trivy turns up in so many pipelines that were only supposed to do one of those things.

What it reads. Container images, filesystems, and SBOM files. It accepts an SBOM as input, so generation and scanning can be split across teams or run at different times without rescanning the image.

Where it is strong. Fast, with a simple CLI and broad registry and CI integration. Outputs CycloneDX and SPDX. For a team running nightly builds or release validation, it works well as a deterministic gate rather than a separate reporting step.

The breadth is the argument. The same binary that produces your SBOM also checks infrastructure-as-code misconfiguration, exposed secrets, and license findings, which means one tool in the pipeline instead of four. Teams running Kubernetes tend to arrive at Trivy for that reason rather than for its SBOM output specifically.

Where it stops. Findings need triage context, as with any scanner, and noise is a real cost at scale. Centralised long-term BOM lifecycle management needs a separate system. Container oriented throughout, so it does not help with a shipped device image.

One piece of history belongs in any evaluation. On March 19, 2026, an attacker with compromised credentials published a malicious Trivy release and force-pushed nearly every version tag in the trivy-action and setup-trivy GitHub Actions to credential-stealing code, tracked as CVE-2026-33634. Exposure windows ran from roughly three to twelve hours, Aqua remediated within days, and v0.35.0 onward is protected by GitHub's immutable releases. The lesson is not about Trivy specifically. Any generator you install through a mutable tag can be replaced underneath you, so pin build tooling to commit SHAs rather than version tags, whichever tool on this list you pick.

Best fit. Pipelines that want the fewest moving parts. Skip it if you need a system of record.

5. cdxgen

OWASP's official generator, and the broadest language coverage in the open-source set.

What it reads. Builds across more than twenty language ecosystems, with transitive dependency resolution for supported ones. Runs as a CLI or as an API server with a /bom endpoint, which makes it easier to wire into workflows that are not shaped like a build step.

Where it is strong. If your codebase is genuinely polyglot, this covers more of it than anything else in the open-source set, and OWASP backing means it keeps pace with new language releases and specification changes.

It also handles container images and OS packages alongside language ecosystems, and generates document types beyond SBOMs, so a team standardising on CycloneDX can produce most of what it needs from one tool. The API server mode matters more than it sounds for organisations where SBOM generation is a service other teams call rather than a step each team wires into its own pipeline.

Where it stops. CycloneDX output only, so SPDX consumers need a conversion step. It can be resource-intensive on very large projects. Kusari also notes that cdxgen runs build tooling in order to resolve dependencies, which is worth knowing if you are running it against code you do not fully trust.

Best fit. Multi-language enterprise codebases where one generator beats six.

6. CycloneDX Language Plugins and npm-sbom

Ecosystem-native generation, and the highest-fidelity option available when your project is one language.

What they read. Your build, through the build tool itself. CycloneDX maintains plugins for Maven and Gradle, npm and Yarn, Python, and Go. npm-sbom is the first-party Node generator, produces both CycloneDX and SPDX, and needs no configuration at all.

Where they are strong. Accuracy, for a structural reason worth understanding. The tool generating the SBOM is the tool that performed the dependency resolution, so there is no second-guessing of a manifest by an outside parser. Independent testing consistently puts ecosystem-native generators at the top for single-language projects, and the reason is architectural rather than a matter of effort.

The Maven plugin is worth configuring rather than accepting at defaults. Scope inclusion decides whether test and provided dependencies land in a document you are about to hand a customer, and those are rarely what you want to declare as shipping.

Where they stop. One plugin per build tool per project, which becomes real overhead across a portfolio. The per-ecosystem CycloneDX projects are also independently governed and make their own decisions about defaults, releases, and command syntax, so output and usage vary between them.

Best fit. Single-language projects where accuracy matters more than uniformity.

7. Microsoft SBOM tool

Built for the case where the build itself is the hard part.

What it reads. Builds at monorepo scale, using Microsoft's component detection library across NuGet, Go, npm, pip, and Cargo.

Where it is strong. Performance and stability on large, complex, multi-language build environments where lighter tools struggle or time out. The component detection library underneath it was built for Microsoft's own build estate, which is a reasonable proxy for scale.

It generates SPDX at build time, capturing dependencies precisely at the point of release rather than inferring them from a manifest afterward. That timing is the quiet advantage: a build-time SBOM describes the artifact that was produced, not the one the lockfile predicted, which matters when resolution is non-deterministic across environments.

GitHub Actions integration is straightforward, the licence is permissive, and Microsoft maintains it openly with active engineering contribution rather than as an abandoned sample.

Where it stops. SPDX only. If a customer or regulator asks for CycloneDX, plan a conversion step or a second tool, and remember that a conversion is another place for data to be lost. Language coverage is also narrower than cdxgen's, so mixed estates may still need both.

Best fit. Large enterprise monorepos, particularly in the .NET ecosystem.

8. Waybill

The newest tool here, and the only one publishing a field-level claim against the 2026 elements.

What it reads. Builds across fifteen language and operating system ecosystems, shipping as a single self-contained Rust binary.

Where it is strong. Transitive resolution that records relationships rather than flattening to a list, optional augmentation from deps.dev, in-toto attestation support, and both CycloneDX and SPDX output. Component identity is handled more carefully than most, which is what makes the graph usable rather than merely present.

The CNCF generates per-release SBOMs with it across more than 1,500 projects and subprojects, which is meaningful because the CNCF is a software steward under the Cyber Resilience Act, so those documents are compliance artifacts rather than experiments.

It also publishes a CISA 2026 coverage document in its repository, which nothing else in this article does. That document carries a per-emitter verdict against all 17 data fields and the 6 practices, each with cited evidence, and an integration test runs the check on every CI build so regressions surface rather than drift. Releases on the stable channel are Sigstore-signed. Whatever you make of a young project, publishing a field-level claim against the current baseline and testing it continuously is the behaviour the rest of the category should copy.

Where it stops. Self-described as alpha, with a small user base. Its publisher recommends it as the compliance option while disclosing that they wrote it, which is honest and still worth weighing.

Best fit. Teams that want the most current compliance posture in open source and can tolerate alpha software. Skip it if you need production maturity today.

9. OWASP Dependency-Track

It does not generate SBOMs. It is here because generating one is the easy half.

What it reads. SBOMs you already have, in CycloneDX, ingested through an API or the UI.

Where it is strong. Continuous re-evaluation against updated vulnerability feeds, so a component that was clean at build time surfaces when a new advisory lands, without rescanning anything or rebuilding the artifact. That single behaviour is why it exists, and it is the difference between a static export and a living SBOM.

Around it sit policy checks with configurable violations, portfolio-level dashboards across projects and versions, an audit trail for decisions, and notification channels so findings reach people rather than a screen nobody opens. It ingests VEX alongside SBOMs, so a supplier's assessment that a vulnerability is not exploitable in their product travels with the inventory instead of being re-litigated locally. For vendor risk, it gives you somewhere to put the SBOMs your suppliers send, which most teams discover they need about a year after they start asking for them. Storing them is not the same as trusting them, and checking a supplier SBOM against the binary it describes is a separate discipline.

Where it stops. Generation is not in scope, so it is always a second tool rather than a replacement. Very large BOM uploads need architectural planning.

An SBOM describes one artifact at one moment. Dependency-Track exists because the useful question is what has changed since, and that is the difference between SBOM generation and SBOM management.

10. FOSSA

The license and attribution specialist, for when the obligation you are managing is legal rather than security.

What it reads. Manifests and source trees, through a CLI designed to run inside an existing build rather than alongside it.

Where it is strong. License detection accuracy beyond what general-purpose tools offer, with detailed mapping of what each license obliges you to do. That distinction carries more weight than it sounds: knowing a component is LGPL is easy, and knowing which artifact you owe a user as a result is the part that takes work. Automated attribution report generation handles documentation that is otherwise assembled by hand under deadline, and the policy workflow engine manages license rules and approvals.

Where it stops. No reachability or exploitability analysis. Security findings exist but are secondary to license compliance and should not be your only control. Teams that arrive looking for a security tool and stay for the attribution reports usually end up running something else alongside it.

Best fit. Companies distributing software that need attribution documentation a legal team will sign. Worth reading alongside what the different open source license families actually oblige you to produce.

What Changed in the SBOM Baseline on July 29, 2026

The 2026 Minimum Elements for a Software Bill of Materials was published by CISA together with the NSA, the FBI, and fifteen international partner agencies. It updates and replaces the NTIA document that most SBOM programmes were built against.

Appendix A lists 17 data fields: nine describing the SBOM document itself, eight describing components. Six practices and processes sit alongside them, Coverage among these rather than in the field table. Ten data fields are new, eight existing elements received major updates, five received minor ones, and one was removed.

Four of the new fields change which tool you should choose.

Component Hash Value is the output of running a cryptographic hash algorithm over an executable component artifact. CISA adds the instruction that decides this: an author without access to that artifact should record the value as unknown. Component Hash Algorithm names the algorithm used, and should come from the IANA hash function names and be approved by a body such as NIST.

SBOM Generation Context records the lifecycle phase and the data available when the SBOM was generated. CISA supplies the worked example itself. An SBOM built from source code can be identified as "before build," and binary analysis tools generate one "after build." We have walked through what that field means for an existing SBOM programme separately. The document defines build as compilation, interpretation, or any other process that makes source code executable.

Component License captures the license identifiers a component is available under, preferably as machine-processable SPDX identifiers.

Three changes to existing elements matter as much as the new fields.

Depth became Coverage. The change log explains that the old element captured top-level dependencies only, and that this reflected what SBOM tooling could do at the time rather than the information security decisions require. There is now no minimum depth, horizontal breadth joins vertical breadth, and multiple instances of a component with differing metadata must each be listed separately.

Known Unknowns became Explicitly Identifying Unknown Information. An author must now state whether missing data is unknown to them or deliberately withheld, and recipients may consider an SBOM incomplete when essential component data is withheld.

Accommodation of Mistakes became Accommodation of Updates. The explanation is the sentence that turns tool selection into a risk decision: data quality has improved enough since 2021 that recipients can expect SBOM data to be accurate, and organisations may weigh errors arising from the selection of inadequate tools in their risk management.

One removal. SWID tags were taken off the list of SBOM data formats, on the stated basis that SWID is not a widely used format with multiple tools behind it. SPDX and CycloneDX are the two formats named.

The Bottom Line

• The baseline changed on July 29, 2026. Ten new fields, Coverage replaced Depth, and SWID came off the list of formats.
• Scan target decides what a tool can find. Most of this category reads builds, and a build is not a shipped product.
• Component Hash Value goes to unknown without access to the executable artifact.
• Selecting an inadequate tool is now explicitly a risk consideration, because the allowance for SBOM error was withdrawn.
• Generation and management are different jobs, and most teams need one of each.

Four branches, and most readers are on the first two.

Single-language project: use the ecosystem-native plugin. Nothing beats the tool that did the dependency resolution.

Polyglot build or container-heavy pipeline: cdxgen for language breadth, Syft or Trivy for containers, Microsoft's tool if the build is the hard part.

Shipped firmware with supplier binaries: you need something that reads the artifact rather than the build, which narrows the field to items 1 and 2. Most manufacturers end up running one of those alongside a build-time generator, because the two answer different questions about the same product.

Already generating SBOMs and losing track of them: the gap is management, not generation. Dependency-Track is where most teams start.

CISA reached a similar conclusion in its discussion of validation, pointing organisations toward binary analysis tools to detect components an SBOM failed to list.

One first move that costs an afternoon. Open the SBOM you would send a customer today. Check whether it declares a generation context and whether components carry a hash. Count the unknowns.

To see what a firmware image reports against one of your own products, request a walkthrough.

Frequently Asked Questions

What is an SBOM tool?

An SBOM tool produces a machine-readable inventory of the components inside a piece of software, in a standard format such as CycloneDX or SPDX. Tools differ mainly in what they read: a manifest, a source tree, a container image, or the compiled artifact that ships.

How do SBOM tools improve software supply chain security?

They convert a question that takes days into one that takes minutes. When a vulnerability is disclosed in a widely used component, a team with current SBOMs can query which products contain the affected version instead of reverse-engineering images or polling suppliers. The same inventory serves license compliance and regulatory filings.

What should you look for in an SBOM generator?

Five things: what artifact it takes as input, which lifecycle phase it can declare, whether it can hash the components it describes, how far it resolves transitive dependencies, and whether it flags what it could not determine. The first decides everything downstream.

Which are the best SBOM tools right now?

There is no single answer, and any list offering one is selling something. Route by scan target. Ecosystem-native plugins win on accuracy for single-language projects, cdxgen and Syft cover polyglot and container workloads, and compiled firmware needs a tool built to read binaries.

Which SBOM tools work on firmware without source code?

Black Duck Binary Analysis and Finite State both generate SBOMs from compiled firmware with no source required. JFrog Xray reads binaries and container layers in Artifactory, though those are artifacts your own pipeline published. The rest of the category cannot inspect a shipped device image.

What changed in the SBOM minimum elements in 2026?

CISA, the NSA, the FBI, and fifteen international partner agencies published the 2026 Minimum Elements on July 29, 2026, replacing the 2021 NTIA version. Appendix A lists 17 data fields, ten of them new, including Component Hash Value, Component License, and SBOM Generation Context. Depth was replaced by Coverage.

Is SWID still an accepted SBOM format?

No. The 2026 update removed SWID tags from the list of SBOM data formats, on the basis that SWID is not widely used with multiple tools behind it. SPDX and CycloneDX are the two named. If your documentation still lists SWID, that reference is out of date.

What is the difference between an SBOM generator and an SBOM management tool?

A generator produces an inventory for one artifact at one moment. A management tool stores those inventories, tracks them across releases, and re-evaluates them as new vulnerability data arrives. Most teams buy the first and discover they needed both.