Today, it’s very difficult to run a successful SBOM (software bill of materials) program without the right SBOM tools.

Although manual (or partially automated) ways of generating, managing, and consuming SBOMs may have worked in earlier generations of software development, today’s realities demand a more sophisticated approach. Not only are modern applications very complex and updated frequently, but there’s a growing need for SBOMs to be created in specific machine-readable formats. Additionally, SBOMs have an increasing number of important use cases, including regulatory compliance, customer requests, open source vulnerability management, and open source license compliance, and tooling should be versatile enough to support all of them.

But with so many SBOM tools on the market today, how can you find the right one for your organization? Different businesses will have different needs, but these capabilities can play particularly important roles in a comprehensive and successful SBOM program.

(For context and clarity: FOSSA's popular SBOM management solution was developed with these principles in mind. Please feel free to get in touch with any questions or if you’d like more information.)

1. Enables Compliance with Regulatory Compliance Requirements

The U.S. government’s 2021 Executive Order on Improving America’s Cybersecurity had a significant impact on the modern SBOM landscape. The executive order requires certain organizations to produce an SBOM to accompany each product. While this mandate is relatively narrow in scope — it directly applies to only federal agencies and companies that do business with them — there’s been a noticeable trickle-down effect.

In the years following the executive order's publication, the FDA (Food and Drug Administration) and PCI DSS (Payment Card Industry Data Security Standard) have added SBOM requirements. The CRA (Cyber Resilience Act) — a massive piece of legislation that impacts the European Union — will have them as well.

And that's not to mention individual organizations that now require SBOMs as a condition of doing business.

Accordingly, we highly recommend ensuring your tooling can produce an SBOM that meets all regulatory requirements that impact your business. Although the specifics do vary slightly — for example, the FDA requires SBOMs to come with end-of-life and level-of-support information for each component, while PCI DSS does not — most regulations borrow heavily from the original 2021 cybersecurity executive order and the minimum required elements for an SBOM.

The NTIA published required data fields for compliant SBOMs

We should note here that, to fulfill regulatory compliance requirements (for basically any common SBOM use case), you will need to find a tool that makes it possible to generate both SPDX and CycloneDX documents. However, most popular SBOM tools do support both specifications, so this likely won't limit your search at all. (The ability to ingest SBOMs in both formats is preferred as well, and this can be harder to find.)

2. Has Comprehensive Programming Language and Ecosystem Support

Another part of producing accurate SBOMs is using a tool with comprehensive programming language and ecosystem support.

We recommend being careful about selecting tools that require you to create SBOMs in one way for a particular ecosystem or language and a different way for another language or ecosystem — but not only because this creates a poor user experience. 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 language coverage conversation with prospective vendors early in the tooling evaluation process.

3. Is Customizable

We mentioned earlier that it’s important for SBOM tools to support multiple export formats and file types. It’s also critical for users to be able to customize the metadata that gets included in a specific bill of materials. This is important because SBOMs have multiple use cases — customer requests, due diligence, security, regulatory compliance, open source license compliance and more — and what makes sense to include in one SBOM might make sense to exclude in another.

And, while different organizations will have different preferences when it comes to customizability, a good general rule is that you should be able to pick and choose:

  • Components included in your report: open source licenses, first-party licenses, direct dependencies, transitive dependencies, copyrights, license headers
  • Dependency metadata included in your report: package, author, description, declared license, discovered license, license header, package URL, full license text, file path, dependency path
  • Format: SPDX, CycloneDX, HTML, plain text, CSV, Markdown

4. Is Easy to Use

The logical place to start when evaluating an SBOM tool’s usability is its user interface. Does the tool require a lot of training to use effectively? Can you go from the homepage to an up-to-date SBOM in a handful of steps? Is it easy to customize which elements to include (and exclude) from your bill of materials?

There are also several technical specifications that can end up having a significant impact on usability. They are:

  • Configuration: You’ll have a superior experience if you don't have to customize the SBOM tool for every language ecosystem
  • Static analysis: Look for SBOM tools that don’t require a runtime integration or tool to use

Another part of usability is how your tool keeps SBOMs up to date. Does the tool automatically generate a new SBOM when there’s a new version of your software? Or does it require a more manual, time-consuming process?

5. Supports Third-Party SBOM Import and Analysis

The ability to import and analyze third-party SBOMs is critical for nearly every common SBOM use case, including security and regulatory compliance. As a starting point, look for SBOM tools that can ingest popular machine-readable formats like CycloneDX. And, consider tools that surface third-party SBOM data in a way that allows you to leverage it.

The goal is to be able to analyze an imported SBOM like you would your own code. For example: Let’s say there’s a new zero-day vulnerability 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).

6. Provides Actionable, Structured Insights

An effective SBOM program has multiple objectives, including satisfying customer requests, complying with regulatory requirements, and reducing software supply chain risk. It's critical to prioritize tools that can operationalize SBOM data to achieve these objectives.

Given that modern applications can have hundreds of open source dependencies, it’s critical to quickly detect issues and take action to address the areas of most significant risk.

SBOM tools can support risk-management initiatives by providing:

  • At-a-glance visibility into vulnerabilities (with the ability to filter by severity) that may impact your project
  • Remediation guidance so you can quickly upgrade affected components to safe versions
  • Automated policy implementation (which can fail builds if your application conflicts with the policies you create to govern open source license compliance and security)
  • Audit-grade reporting allows users to annotate security and licensing concerns to isolate mitigated risk from active risk

7. Has Breadth and Depth

An SBOM is only as useful as it is accurate. And, two of the biggest factors that contribute to SBOM accuracy are the breadth and depth of your tool’s coverage.

Breadth: Can the tool scan all of your projects with a base level of SBOM coverage? You don’t want a scenario where it’s difficult or even impossible to integrate your tool with certain repositories.

Depth: Can the tool detect not only your direct dependencies but also transitive dependencies? Are there limits to how many layers of transitive dependencies?

Often, SBOM tools that offer breadth and depth 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 assess risk during application delivery

8. Supports Third- and First-Party Elements

The vast majority of the code in modern applications is open source; some estimates peg this number around 90%. So, it goes without saying that SBOMs tools will need to be able to detect and report on your open source components.

But an SBOM won’t be accurate unless the tool used to generate it supports all software components in a given application — including those built in-house and acquired from commercial suppliers. Specifically, look for SBOM tools that:

  • Provide complete dependency graph coverage; even without access to a component, your SBOM tool should still be aware of the component(s), allowing you to annotate missing information when desired.
  • Analyze these components as binaries to find license information
  • Tell you what other projects are using your in-house components to assess the impact (how pervasive the issue is throughout your organization) of any determined risks

9. Has a Secure Distribution Portal

Comprehensive tools need to do more than generate, ingest, and analyze SBOMs. They also need to facilitate secure SBOM distribution. 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, and often with time-based access control. If distribution is involved in one of your SBOM use cases, we recommend looking for a solution that comes with sharing capabilities.

The Bottom Line

There’s no one-size-fits-all approach to picking the right SBOM tools, but there are certain capabilities that, generally speaking, play important roles in a successful SBOM program. And, we hope this list serves as a useful starting point as you begin to evaluate the numerous SBOM tools on the market today.

FOSSA’s suite of open source license compliance and security products includes a widely used SBOM tool; in fact, leading analyst firm Forrester awarded our platform the highest score possible for SBOM support.

If you’d like more information on using FOSSA to generate, import, and/or manage SBOMs, please feel free to get in touch with our team by filling out the form on this page.

FAQ: Sizing Up SBOM Tools

What are the most important features of a good SBOM tool?

Every organization will have different needs, but, generally, we recommend SBOM tools that:

  • Enable compliance with regulatory compliance requirements
  • Have comprehensive programming language and ecosystem support
  • Can ingest third-party SBOMs and analyze them for licenses and vulnerabilities
  • Are easy to use and can produce highly customizable SBOM documents
  • Provide actionable insights (such as vulnerability prioritization and remediation support)
  • Offer both breadth and depth of coverage
  • Come with a secure distribution portal.
  • Why is programming language coverage important for an SBOM tool?

    Because it ensures consistent and accurate SBOM generation across different programming languages and ecosystems. Using different tools for different languages can lead to inconsistencies in interpreting SBOM fields, potentially causing significant issues. A tool with broad support can also better handle edge cases and nuances specific to certain languages or package managers.

    What formats should SBOM tools support?

    You should have the ability to produce and ingest SBOMs in both CycloneDX and SPDX. This is important because SBOMs have various use cases, such as customer requests, due diligence, security, regulatory compliance, and open source license compliance. Different formats may be required for different purposes, and the ability to customize and translate between formats allows for tailoring the SBOM to specific needs.

    FOSSA Principal Product Manager Cortez Frazier Jr. contributed to this article.