The 4 Best SBOM Generation Tools Compared (Updated for 2026)

TL;DR: The best SBOM tools depend on your stack and your goal. For Java/Maven or Gradle projects on a tight budget, CycloneDX produces the cleanest, most readable output. For enterprise teams that need an easy-to-deploy SBOM that also turns components into a full risk picture (vulnerabilities, licenses, VEX), Finite State is the best choice.

Software supply chain security is a higher priority than ever, and software bills of materials (SBOMs) are a key tool organizations use to keep their applications safe.

A good software application is always changing: software companies are constantly fixing bugs, adding capabilities, and improving the user experience. In addition to these changes, the third-party libraries these companies incorporate in their applications are also constantly being updated to improve performance and eliminate known vulnerabilities—which means many software companies sell applications built on out-of-date third-party code.

With both proprietary code and components in such a state of flux, it’s important for companies to generate comprehensive and accurate SBOMs—whether it’s for themselves or for hopeful vendors.

In order to do this, organizations invest in tools that can provide SBOMs for the software they create as well as for the software they consume. As part of our ongoing effort to help people choose SBOM generators, we’ve analyzed some of the most well-known SBOM generators on the market today to see which ones lend the biggest hand to software providers.

What is an SBOM tool?

An SBOM Management tool inventories every component in a piece of software, your own code plus third-party and transitive dependencies, and outputs a machine-readable list you can scan for risk.

A software bill of materials is essentially an "ingredients list" for software. Because applications constantly change and pull in updated third-party libraries (many with newly disclosed vulnerabilities), a static list written by hand goes stale fast. SBOM tools automate that inventory so it stays accurate across the build and shipping cycle. U.S. federal guidance now treats SBOMs as a key building block for software supply chain risk management.

What to look for in an SBOM generator

The completeness point is the one most teams underestimate. The NTIA Minimum Elements for an SBOM explicitly require that when a tool cannot enumerate the full dependency graph, it must flag those gaps as "known unknowns" rather than silently omit them, which is a useful test of any tool's honesty about what it actually found.

Which are the best SBOM tools right now?

The four SBOM tools worth comparing for most teams are CycloneDX, Syft (by Anchore), Fossa, and Finite State. All generate multi-format SBOMs and include dependency data.

We focused on these four because we already know they perform well, incorporate dependency information into the SBOM, and support multiple SBOM formats. Here is how they stack up across the criteria above:

Those tools are CyclineDX, Sfyt (by Anchore), Fossa, and, of course, our own Finite State.

A few key notes before we dive in:

• Every one of these tools can generate SBOMs in both XML & JSON formats.
• This report is based on my use of these tools using available documentation. (For example, if Fossa can generate an SBOM from a Docker image, I haven’t found any reliable documentation about it.)
• In addition to these tools, Snyk’s AppSec software can also generate SBOMs—however, this is only available at the enterprise plan level, so we left Snyk out of this comparison round.

How did we test these SBOM tools?

We built identical single-import Java projects in Maven and Gradle (importing Twilio, which carries the Log4j dependency), then ran each tool through generation from source, from a build, and from a Docker image.

To stress-test source independence, we split the project into four folders: Gradle compiled, Gradle uncompiled, Maven compiled, and Maven uncompiled. For the Docker exercise we built a small image and manually copied a single vulnerable jsch-0.1.55.jar into /opt/jsch/, simulating software added via COPY instead of a package manager. A dependencies.txt file (sourced from deps.dev) gave us ground truth for the full Twilio dependency tree.

Every tool caught every transitive dependency except lombok, which, given the consistency across tools, looks more like a deps.dev artifact than a tool flaw. This reproducible setup is the part most roundups skip, and it is where the real differences surfaced.

How good is CycloneDX for SBOM generation?

[Gradle plugin | Maven plugin]

CycloneDX founder Steve Springett is profoundly proficient with Maven and Java—at the time of running these tests, he had made 324 commits to this project (out of 403 total commits to the tool). The result is an SBOM that’s as good as SBOMs get. It’s a document that can be read by machines and humans alike. Bravo, CycloneDX!

If you’re building a Java/Maven project, I can’t recommend CycloneDX highly enough: I’d enable it and start including it in your build as soon as possible.

In order to use CycloneDX, you’ll need to use the plugin compatible with your build tool. I’ve listed my notes from this test for each plugin below. This is the main drawback that I found in terms of ease of deployment and use: you need to find and install a different plugin for each language and build in each project’s dependency file, which could get onerous with large projects.

CycloneDX (Gradle plugin) notes

Generating an SBOM without source code:

• 
  You need to run gradle wrapper in order to run the ./gradlew cyclonedxBom command, but don’t run ./gradlew build.
  

You need to run gradle wrapper in order to run the ./gradlew cyclonedxBom command, but don’t run ./gradlew build.

gradle wrapper

./gradlew cyclonedxBom

./gradlew build.

Generating an SBOM from build (source code available):

• When running the tool in build, run ./gradlew build first, then gradle wrapper in order to run the ./gradlew cyclonedxBom command.

./gradlew build

gradle wrapper

./gradlew cyclonedxBom

Deploying CycloneDX for SBOM generation:

• All you need to do is add the “org.cyclonedx.bom” dependency to the build.gradle file, which is also where you can configure how you want CycloneDX to generate the SBOM.

CycloneDX (Maven plugin) notes

Generating an SBOM without source code:

• Do NOT run mvn clean install . Instead, just run mvn org.cyclonedx:cyclonedx-maven-plugin:makeBom

mvn clean install .

mvn org.cyclonedx:cyclonedx-maven-plugin:makeBom

Generating an SBOM from build (source code available):

• This is a nice touch: every time you run mvn clean install it creates both the JSON and the XML SBOMs in the target folder.

mvn clean install

Deploying CycloneDX for SBOM generation:

• Just add the dependency to the pom.xml file and you’re good to go.

Additional comments:

• Based on our own Maven and software-composition expertise, here at Finite State, we recommend the following configuration when using cyclonedx-maven-plugin:

<includeCompileScope>true</includeCompileScope>                
<includeProvidedScope>false</includeProvidedScope>                
<includeRuntimeScope>true</includeRuntimeScope>                
<includeSystemScope>false</includeSystemScope>                
<includeTestScope>false</includeTestScope>

Is Syft a good free SBOM tool?

For a free, open-source tool, Syft is an effective SBOM generator. Syft is very easy to operate and will do exactly what you tell it to do—which means you need to be specific when telling Syft what to scan. (Be careful not to accidentally tell it to scan your complete filesystem!)

While Syft provided, on the whole, accurate analyses, I did have a few qualms. For example, Syft did find every transitive dependency. However, it only did so for the post-build directory scan, and presented the report as a flat list rather than a series of interconnected relationships. In addition to this, Syft returned more than 830 spurious entries in the resulting JSON file. When I reviewed the JSON SBOM, I found a long string of this nonsense:

{
  "name": "syft:cpe23",
  "value": "cpe:2.3:a:apache_software_foundation:log4j:2.14.0:*:*:*:*:*:*:*"
},
{
  "name": "syft:cpe23",
  "value": "cpe:2.3:a:apache_software_foundation:api:2.14.0:*:*:*:*:*:*:*"
},
{
  "name": "syft:cpe23",
  "value": "cpe:2.3:a:Activator:log4j_api:2.14.0:*:*:*:*:*:*:*"
}

Aside from this, Syft works rather well at generating SBOMs.

Is Fossa a reliable SBOM tool?

Fossa is an easy enough tool to use. However, the CLI command doesn’t generate SBOM files directly into your project—you’ll have to move it there yourself.

By default, Fossa generates SBOMs using SPDX’s plain-text format, rather than in XML or JSON. This makes the file less machine-readable—but the resulting text is not very human-friendly, either:

SPDXVersion: SPDX-2.1 DataLicense: CC0-1.0 SPDXID: SPDXRef-DOCUMENT Creator: Organization: FOSSA, INC. Created: 2022-08-09T10:45:17Z PackageName: Apache Log4j API PackageVersion: 2.14.0

Unfortunately, the plain-text SBOM file Fossa generated was not particularly useful. I would much rather get a file that easily maps packages to Maven-Central coordinates (e.g., groupId=**org.apache.logging** and artifactId=**log4j-api**), or even an SBOM that used PURL to help me see where packages are. This is more aligned with how developers think and talk about dependencies, which would make Fossa’s SBOMs much more useful.

groupId=**org.apache.logging**

artifactId=**log4j-api**

In addition to these issues, the license information in Fossa’s SBOM output seemed nonsensical to me:

PackageLicenseDeclared: Apache-2.0
PackageCopyrightText: ownership.
PackageLicenseInfoFromFiles: Apache-2.0
PackageLicenseInfoFromFiles: MIT
PackageLicenseInfoFromFiles: Apache-1.1

I manually analyzed the “Log4J-API-2.14.0” package to verify these claimed licenses, and found absolutely no evidence suggesting that MIT or Apache-1.1 were appropriate here. Not only is this inaccurate, but such an error could cause bigger problems, as Apache-1.1 is famously incompatible with GPL software.

What makes Finite State different?

Finite State generates an SBOM in one click and, because it analyzes binaries (including Java and .NET), needs no source code, while automatically producing a VEX report and a full risk analysis.

This is where the "generation is only step one" point matters most, and it is why Finite State fits enterprise teams especially well. Finite State does not just produce SBOMs. It also imports and scans SBOMs you receive from suppliers, then turns them into a risk picture showing known vulnerabilities and where they live, license and legal risk, and technical debt across your supply chain. It also gives developer guidance, prioritizing issues and pointing to available patches, so you move from inventory to action without a second tool.

Which SBOM tool is best for you?

Pick based on goal: CycloneDX for budget-conscious Maven/Gradle teams, Syft for free broad coverage, and Finite State for enterprise teams that need easy deployment plus built-in risk analysis.

If you are working in Maven or Gradle on a shoestring AppSec budget, CycloneDX is the way to go. For enterprise teams that want an easy-to-deploy, highly accurate SBOM that also tells you where your risks lie and how to fix them, Finite State is the best choice. If you would like to see how Finite State can help secure your software supply chain, you can start a free trial.

Frequently asked questions

What are the best practices for implementing SBOM generation tools?

Generate SBOMs automatically inside your CI/CD build, cover both source and binaries, capture transitive dependencies, flag "known unknowns," and standardize on a recognized format.

In practice that means wiring generation into the pipeline (so every build produces an SBOM), using a tool that handles your specific build systems and languages, and validating that the output captures nested dependencies rather than just top-level packages. The NTIA Minimum Elements call for explicitly labeling gaps as "known unknowns," and modern guidance stresses that an SBOM is only useful once it is mapped to vulnerability and license data, so plan for the analysis step, not just generation.

What are the common challenges faced when using SBOM generation tools?

The most common challenges are incomplete transitive dependency capture, noisy or duplicate output, inaccurate license data, format inconsistencies, and managing a different plugin per build tool.

Our testing surfaced all of these. Syft returned more than 830 spurious entries and a flat dependency list, Fossa emitted questionable license claims and an awkward plain-text default, and CycloneDX, while accurate, requires a separate plugin per build environment. Format fragmentation is another friction point, and many teams end up supporting both CycloneDX and SPDX to satisfy different customers and regulators.

What are the costs associated with SBOM generation tools?

SBOM tool costs split into two models: free open-source tools (CycloneDX, Syft) with no licensing fee, and commercial platforms (Fossa, Finite State, Snyk) priced by quote or plan tier.

Open-source tools carry no license fee, but factor in the engineering time to deploy, maintain, and triage their output. Commercial platforms cost more upfront but bundle the analysis, prioritization, and management that turn a raw SBOM into action. Pricing for commercial options changes over time, so confirm current figures with each vendor.