The SBOM Tool Buyer's Guide

Over the past few years, a growing number of organizations have started using SBOMs (software bill of materials) to manage a variety of regulatory requirements, customer requests, and software supply chain security initiatives. As you might expect, the growth in SBOM adoption has also led to a significant increase in the number of SBOM tools on the market.

Due to the extremely broad range of organizations that use SBOMs — with different-sized teams, different use cases, different development environments, and different resources — our view is that there’s no single “best” SBOM tool for everyone. What’s most effective for a small engineering department that builds applications primarily in one programming language (and has no commercial software suppliers) might not make sense for a large enterprise that uses many languages and software suppliers.

With that said, there is certainly a common set of capabilities we think many organizations (especially larger enterprises) will find particularly important when evaluating SBOM tools and vendors. This buyer’s guide will explore our top five.

1. Has Comprehensive Programming Language and Ecosystem Support

Let’s start with the obvious. If your team or organization builds single-language applications, this might not matter much to you. (In fact, if you’re in this category and are focused on SBOM generation, you may be able to succeed with an ecosystem-specific open source tool, like npm-sbom.)

But for larger enterprises and/or teams that build multi-language applications — or ingest SBOMs from suppliers that build multi-language applications — the best SBOM tool will generally be one with broad support. If the tool is unable to scan all of your projects with a base level of coverage, it’s likely your SBOM will be incomplete or inaccurate.

In this scenario, you might have to piece together multiple tools to get coverage. This not only creates a poor user experience, but it can also lead to inconsistent and possibly inaccurate results caused by each tool’s unique interpretation of SBOM fields. For example, a tool may interpret the package supplier as the author of the package, the author’s parent organization, the package manager distributing the package, the registry hosting the package, or a combination of the above. Multiply these inconsistencies by the number of fields in any SBOM, and you can see how significant issues may arise.

An important related capability is how well the SBOM tool (and/or the vendor behind it) can handle the sorts of edge cases that will inevitably pop up, especially for larger and more complex engineering organizations. For example, just because a tool claims to support Yarn doesn’t mean it will necessarily be able to navigate the nuances of Yarn 1 vs. Yarn 2. Or Go projects before and after the introduction of Go modules.

We encourage organizations to have the coverage conversation with prospective vendors early in the tooling evaluation process because of its importance.

2. Checks Your Generation Boxes

The SBOM tooling market has matured to a point where there are a number of tools that can reliably generate basic SBOMs (so long as the tool supports your programming languages and ecosystems). But there are a few particular generation-related capabilities that certain types of organizations may find particularly valuable.

1. Comes ready for regulatory compliance: Most SBOM compliance requirements (such as DORA, PCI DSS, and the FDA) generally have some overlap (like leveraging the NTIA minimum elements as something of a baseline), but there are meaningful differences too. If your organization is subject to one of these requirements, make sure your tool can output an SBOM with the mandated data fields, structural elements, and dynamic analysis such as support status. Bonus points if the tool has a pre-formatted SBOM module purpose-built for your specific compliance requirement.


2. Is fully customizable: In addition to producing an SBOM in the format of your choice, you should be able to pick and choose from a wide range of components (e.g., open source licenses, direct dependencies, transitive dependencies, copyrights) and metadata (e.g., package name, download URL, package author) when configuring your SBOM.


3. Has automatic updates: Keeping an SBOM accurate requires organizations to update the document when the composition of their application changes. Depending on your tool, this can be a very manual process or a fully automated one. Generally, the best SBOM tools will automatically update an SBOM whenever a new source code change is released (and the associated scan is triggered) and/or whenever a new supplier SBOM is ingested.


4. Can automatically create VEX annotations: VEX (Vulnerability Exploitability Exchange) is a set of formats that organizations can use to communicate vulnerability exploitability in or alongside their SBOMs. Whenever you investigate a vulnerability but determine it to be non-exploitable, you should have the option to add a VEX annotation that reflects your status and justification with just a few clicks.

3. Can Ingest, Analyze, and Aggregate Third-Party SBOMs

Larger enterprises — especially those that purchase software from suppliers — will often find it important to be able to ingest and analyze third-party SBOMs as part of supplier risk management and regulatory compliance initiatives.

If your company is in this category, we recommend you consider an SBOM tool with support for:

1. Ingesting both CycloneDX and SPDX SBOMs.


2. Combining first- and third-party SBOMs into a single, application-level SBOM (that can then be delivered to customers or regulators).


3. Analyzing an ingested SBOM like you would your own code. For example: Let’s say there’s a new zero-day vulnerability or malicious package impacting a certain open source library. You should be able to analyze the third-party SBOM to quickly determine whether the application relies on the open source component (and, if so, whether it uses a vulnerable version).


4. Applying SBOM Policies: The ability to natively enforce SBOM standards across both external supplier networks and internal teams to ensure their ingested SBOMs meet requirements for data fields and file formats significantly reduces back-and-forth.


5. Enriching SBOMs: Not every SBOM you receive from your suppliers will be complete. Ensure your tooling is capable of taking SBOM components (whether from unique identifiers like PURL or approximation matching) and adding missing metadata such as suppliers, relationships, support status, vulnerabilities, or license attribution.

4. Is Easy to Use

An important starting point for determining which SBOM tool is best for your business is ensuring your team will actually be able to use the tool. We think of tool usability in three broad buckets:

Integration Points

Generally, the best SBOM tools will have multiple integration points to analyze component usage during every phase of the software development lifecycle. This includes:

• VCS integration during code generation to quickly ensure all projects receive a base level of coverage.
• CI integration during the build phase (pre-application deployment) to assess risk in components included at build time.
• CD integration, including container scanning, to determine risk during application delivery.

This is the case because what’s in your software at source or build time (CI) — such as compile, dev, or test dependencies — will not exist during containerization and deployment (CD). Your SBOM tool should be capable of tagging these types of changes, such as with FOSSA’s Package Labels feature.

User Interface

You should not need extensive training to get value from an SBOM tool. You should be able to get from Point A (e.g., opening the tool’s web app or your CLI) to Point B (e.g., an up-to-date SBOM) in a handful of steps. It should also be easy to customize which elements to include (and exclude) from your bill of materials.

Additional Technical Specifications

• Configuration: You’ll have a superior experience if you don't have to customize the SBOM tool for every language ecosystem. A tool should intelligently decide which scanning method and fallback methods to use based on the type of inputs (static analysis, dynamic analysis, containers, etc.) provided.
• Scope-based analysis: When evaluating SBOM tools, look for ones that account for dependency scopes. A good tool should distinguish between packages that are actually part of the delivered application and those only used for building, compiling, or testing, rather than automatically treating every detected package as a production dependency.

5. Makes Sharing SBOMs Secure and Efficient

Comprehensive tools need to do more than generate, ingest, and analyze SBOMs. They also need to facilitate secure SBOM sharing. As more and more customers (and regulatory bodies) require SBOMs as a condition of doing business, SBOM producers are increasingly expected to have a way to share SBOMs only with authorized recipients, with end-to-end encryption and access controls. If distribution is involved in one of your SBOM use cases, we recommend looking for a solution that:

• Has full security measures (such as RBAC, encryption, and signing) to safeguard the contents of your SBOM.
• Has a policy-driven workflow, where the sharing feature helps ensure the provider distributes an SBOM with the format and fields that meet the SBOM consumer’s requirements.

What’s the Best SBOM Tool for My Organization?

Ultimately, there’s no one-size-fits-all approach to picking the best SBOM tool. However, as we've discussed, there are certain capabilities that tend to play important roles in a successful SBOM program. These include comprehensive language coverage, strong SBOM generation features, the ability to ingest and analyze third-party SBOMs, ease of use, and support for secure SBOM sharing.

We hope this buyer’s guide serves as a useful starting point as you begin to evaluate the numerous SBOM tools on the market today. If you’d like more information on using FOSSA’s popular SBOM management solution to generate, ingest, analyze, or share SBOMs, please feel free to get in touch with our team.