Skip Navigation
Resources Blog SBOM – From the idea of transparency to the reality of code

SBOM – From the idea of transparency to the reality of code

Code vulnerabilities are growing in frequency and impact. As software is increasingly made up of parts from many different vendors, often referred to as the software supply chain, it can be hard to find and fix them quickly. In one recent example, a software team found an IP vulnerability and had to track down the Fortune 100 company that could fix it via LinkedIn in order to make them aware.

One solution to this problem is to use a software bill of materials (SBOM). Allan Friedman, director of cybersecurity initiatives at the US Department of Commerce's National Telecommunications and Information Administration (NTIA), who was a Keynote at Sonatype's recent ELEVATE user conference, shared how critical it is to be transparent in the inner workings of code via an SBOM.

What is an SBOM?

An SBOM is a series of metadata that describes a software package's dependency tree. It includes key information like the supplier, version number, and component name. These basic details like these are critical when analyzing software for vulnerabilities, as are rooted in a variety of component parts, as detailed in the flowchart below (Figure 1).

Example SBOM elements

Figure 1: Example SBOM elements

What is the value of an SBOM?

Transparency helps markets thrive. For example, food ingredients and labels give people the knowledge they need to make intelligent decisions. Labels don't guarantee people will eat healthy, but it gives them the information to make healthy eating choices. Similarly, an SBOM won't automatically solve all security problems, but it does empower teams to solve them faster and easier.

SBOMs can also tell you a lot about a software component. For example, if you see that there are six versions of a package in an SBOM, there's a high risk that one of them is vulnerable.

The capabilities go beyond just vulnerabilities and into redundancy. For example, the question of how many open source projects are dependent on just one component. This is described as the "Ukulele Problem," or the project owner might just give up the hobby by taking up the ukulele and strand all the dependent projects.

Why aren't we doing this today?

There are many reasons for SBOMs not being a standard practice today. While they are gradually gaining a foothold, there remains a chicken-and-egg problem where no one is asking for it, and so it's not provided.

Additionally, an SBOM isn't necessarily easy to create across supply chains. As a new concept, the industry struggles with best practices and tooling around it. For example, an SBOM requires consistent naming, where vendors and even coworkers in the same group may give the same component different names.

There are also licensing and open source concerns.

How to build an SBOM

There are few guiding principles for making SBOMs with NTIA's process. Most important is realizing that you have to crawl before you can walk. A baseline SBOM is necessary so teams can align around it. Created SBOMs need to be machine-readable so that they can easily be automated, and then posted to a known or discoverable location to make it easy to access and analyze.

How to implement an SBOM

There are three formats to implement an SBOM today:

  1. SPDX: A grassroots effort by the Linux Foundation. The program is an open standard for communicating SBOM information, including components, licenses, copyrights, and security references.
  2. CycloneDX: Purpose-built for security contexts and supply chain component analysis.
  3. SWID tags: Made up of files that record unique information about a software component and help with inventory management initiatives.

SBOM example

An important proof-of-concept was in the health care sector, leveraging a bill of materials to find vulnerabilities and exploitable components. It also allowed software issues with important medical devices to be called out to vendors.


While there's much up-and-coming tooling available to make SBOMs, NTIA has a tooling taxonomy to help teams choose the right one (Figure 2 below).

SBOM tooling taxonomy

Figure 2: SBOM Tooling taxonomy

The taxonomy centers around SBOM:

  • Production: It's important to be careful when choosing your SBOM's format and outputting artifacts, as well as analyzing and editing existing lists.
  • Consumption: Good tooling lets teams read contents and compare between SBOMs to detect differences.
  • Transformation: Multiple sources of SBOMs and other data can be combined together for auditing.

NTIA also encourages interoperability among tools so that everyone together can bring more awareness and increase usage.

Governmental recognition

As was accomplished with medical devices (a matter of life and death), SBOMs should be feasible to do this for other industries and applications, as noted in Figure 3, below.

SBOM - From the Idea of Transparency to the Reality of Code by Allan Friedman v3_html_2cb633872f52495b

Figure 3: NTIA SBOM considerations

The current administration recognizes the importance of cybersecurity and released an Executive Order, describing SBOMs and their value proposition in Section 4.

The future of SBOMs

Not just in the US but globally, governments and industry are seeing SBOMs as increasingly critical to security. We're seeing a future where SBOMs are recognized and leveraged.

There's a vision of more organizations leveraging SBOMs and helping the community to refine the tooling to meet broader needs in the industry. SBOM are not the solution to all your security concerns, they are recognized as part of smart security decisions by teams.

About the presenter: Allan Friedman is the Director of Cybersecurity Initiatives - US Department of Commerce, NTIA.

Picture of Mark Henke

Written by Mark Henke

Mark Henke has spent over 10 years architecting systems that talk to other systems, doing DevOps before it was cool, and matching software to its business function. Every developer is a leader of something on their team, and he wants to help them see that.