SBOM Starter Kit: Get Your Copy
SBOMs (software bill of materials) are structured documents that inventory the software components in a given application. Depending on the intended use case, SBOMs can also communicate information about software licenses, vulnerabilities, and other metadata relevant to software transparency.
SBOMs have become increasingly relevant in recent years due to a series of new regulations and a heightened focus on software supply chain security.
On the regulatory compliance front, the Biden Administration's 2021 cybersecurity executive order mandated SBOM creation for organizations that sell into the U.S. federal government. That was followed by additional SBOM-related requirements from bodies like the FDA, PCI-DSS, and EU (Cyber Resilience Act). At the same time, more and more security teams started using SBOMs as a tool for managing software supply chain security and requiring them from upstream suppliers.
As the SBOM ecosystem has grown, it’s also become more sophisticated. The two primary machine-readable SBOM specifications (SPDX and CycloneDX) now collectively support hundreds of different data fields. New tools that automate various parts of the SBOM management lifecycle are being released seemingly every week. And, new SBOM-adjacent formats like VEX (for vulnerability management) are emerging to support specific SBOM use cases.
In this guide, we’ll attempt to demystify the complex world of SBOMs. We’ll start by discussing the contents of an SBOM itself — its format, elements, and structure. We’ll also cover how organizations are using SBOMs as a supply chain security tool, SBOM license compliance use cases, and tools that can automate SBOM lifecycle management.
There isn’t a universal standard for what constitutes a valid SBOM. But, in practice, most SBOMs include a common set of data fields that describe an application’s components.
These data fields align with guidance from the U.S. federal government NTIA on the minimum elements of an SBOM. They are:
For additional context, "other unique identifiers" may refer to Software Identification (SWID) Tags, Package Uniform Resource Locators (PURL), Common Platform Enumeration (CPE), or other such identifiers. Also, “dependency relationship” means, essentially, how and where different software components fit together. Per the NTIA, it "enables the representation of transitivity from a piece of software to its component and a potential sub-component."
In addition to those seven data fields, the U.S. government’s requirement — which is also a non-negotiable for modern security teams — is that the SBOM be transmitted in a machine-readable format such as CycloneDX or SPDX. We’ll discuss both in more detail later in this article.
Finally, the U.S. government’s SBOM requirements also include a “practices and processes” section on how and when SBOMs should be updated and delivered. Again, these are only required for organizations selling into the U.S. federal government, but they’re also best practices for most SBOM use cases. This section covers areas like how often SBOMs should be produced (after new builds or release), what dependency depth they should include (transitive and direct), and how SBOMs should be distributed (in a “timely” fashion and with access controls in place.
There are two full-stack SBOM formats commonly used today: SPDX (System Packet Data Exchange, formerly Software Packet Data Exchange) and CycloneDX. These are also of the three approved formats in the U.S. government’s cybersecurity executive order; SWID is the other, but, unlike CycloneDX and SPDX, SWID is not a complete SBOM specification
SPDX SBOMs can be generated in .xml, .json, and .yaml file formats (among others), while CycloneDX can be generated in .xml. .json, and Protocol Buffers.
Software Identification (SWID) Tags are also covered in the executive order, but the format requires more engineering effort to implement and is far less popular than SPDX and CycloneDX. However, when implemented, SWID has excellent utility as a descriptive means to both describe individual software components as well as their existence within deployed products
In addition to these SBOM specifications, it's certainly possible to communicate SBOM information in other formats and structures. For example, FOSSA users can generate a listing of all their software components in HTML, Plain Text, Markdown, PDF, and CSV in addition to SPDX and CycloneDX. But, in practice, most organizations produce and consume SBOMs in either SPDX or CycloneDX.
Like we mentioned, regulatory compliance has been one the primary driving forces behind the increase in SBOM adoption across the globe. We’ll focus here on four of the most influential requirements impacting the broadest set of organizations: Executive Order 14028, the Cyber Resilience Act, the FDA’s cyber device regulations, and PCI-DSS 4.0.
The chart below includes a high-level overview of each regulation, the parties impacted, and implementation timelines.
Software supply chain attacks like Log4Shell have put a premium on the importance of being able to quickly determine whether (and where) organizations use specific software components. SBOMs are quickly becoming a vital tool to facilitate not only this sort of zero-day vulnerability response, but other security use cases as well.
Here’s a look at some of the most important ways SBOMs support security teams:
The vast majority of modern applications use a lot of open source, and SBOMs can help maintain visibility into potential open source vulnerabilities.
This works in two ways. One is that the SBOM itself should include up-to-date information on the specific component name, version, and a unique identifier. When a new high-risk vulnerability is made public, you’d be able to search the SBOM to determine whether the product includes an affected version of the component. Additionally, tools like FOSSA consolidate SBOMs across your applications and allow organizations to search by CVE or component/component version to find vulnerabilities across their entire open source ecosystem.
It’s also important to note that SBOMs don’t just help organizations identify vulnerabilities in their codebase. Ingesting SBOMs from software suppliers can help companies understand and mitigate software supply chain risk from third parties as well.
VEX (Vulnerability Exploitability eXchange) is a set of formats that communicate information on whether a vulnerability is actually exploitable in a given product — or, more commonly, a justified assertion of not being impacted. Since the vast majority of the tens of thousands of vulnerabilities that get reported each year aren’t attackable, VEX helps organizations focus remediation on the ones that are.
Both the CycloneDX and SPDX SBOM formats support VEX. You can either embed VEX information directly in the SBOM, or you can reference an external VEX document (recommended in most cases).
In addition to helping understand vulnerability exploitability, SBOMs (and SBOM tools) support proper remediation. When you use an SBOM tool like FOSSA, it will surface contextual information like CVSS score, EPSS score, origin path of the component, and remediation guidance (including the next safe version), along with the vulnerability.
The roots of modern SBOMs can be traced back to 2011, when the first version of the SPDX specification was released. At the time, SPDX was primarily intended to serve license compliance use cases — the Linux Foundation (which manages SPDX) announced the format as a pillar of its Open Compliance Program.
And, although SBOMs are now often created for security and regulatory compliance purposes, open source license compliance remains an important use case as well.
SPDX has specific properties designed to communicate licensing information: License Identifiers and License Expressions. License Identifiers are standardized abbreviations for common licenses, like “Apache-2.0” for the Apache License 2.0. License Expressions are used to provide additional context for nuanced situations like multi-license and choice-of-license scenarios.
CycloneDX also does support SPDX License Expressions and Identifiers, which helps standardize license compliance across formats, in addition to full license names.
We should also note that, for many organizations, producing SBOMs for license compliance purposes starts at the tooling level. For example, when you generate an SBOM in FOSSA, there’s an option to include (or exclude) a wide range of licensing data fields (such as full license text, declared licenses, and discovered licenses). If your SBOM consumer is compliance-focused, we’d certainly recommend you consider including this data in your bill of materials.
Given the complex nature of modern applications — and the fact that SBOMs are expected to be produced in a machine-readable format — automation is now widely considered a mission-critical part of a scalable SBOM program. And, as you might expect, there is a wide range of SBOM tools on the market today, including free and paid options.
Although different organizations have different SBOM priorities, mature programs will often require tools with the following capabilities:
Organizations can use FOSSA’s SBOM management platform for a wide range of SBOM-related activities. Here’s a quick overview. (Note that you can also manage SBOMs with FOSSA’s CLI and API.)
FOSSA paid users can import, consolidate, and analyze third-party SBOMs in either SPDX or CycloneDX. Here’s how: