The Complete Guide to SBOMs

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 been around for decades, but they've gained significant traction in recent years due to a combination of regulatory requirements and growing awareness of software supply chain security risks. 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).

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.

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:

• Supplier Name
• Component Name
• Version of the Component
• Other Unique Identifiers
• Dependency Relationship
• Author of SBOM Data
• Timestamp

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.

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.

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.

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:

Providing Visibility into Vulnerabilities

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.

Supporting VEX and Remediation

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:

1. SPDX and CycloneDX Support: Most tools provide the ability to produce SBOMs in CycloneDX and SPDX, but it's a good idea to determine if a tool can ingest SBOMs in those formats as well.
2. Extensive Programming Language and Ecosystem Coverage: Your SBOM won't be accurate if your tool doesn't support your programming languages.
3. Customizability and Simplicity: Your SBOM tool should be able to export reports in multiple formats and file types. It should also be easy to customize the data fields that are included in your document.
4. SBOM Import and Analysis: In addition to being able to ingest SPDX and CycloneDX SBOMs, tools should be able to analyze (e.g. surface associated vulnerabilities and licenses) the data from those SBOMs.
5. Actionable Insights: Of course, just surfacing vulnerabilities and listing software components only goes so far. SBOM tooling should also support vulnerability remediation by providing prioritization inputs (e.g. EPSS and CVSS), recommended fixes, and tight integrations with developer-preferred ticketing workflows.
6. Breadth and Depth: Your tool's ability to both a) provide base coverage across projects and b) detect transitive in addition to direct dependencies impacts SBOM completeness and accuracy.

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.)

Generating SBOMs (Available for free and paid accounts)

• Step 1: If you haven't already, sign up for a FOSSA account and import your project(s).
• Step 2: Navigate to the FOSSA project or Release Group you'd like to represent in your SBOM. Then, select "Generate SBOM Report" from the menu on the right side of the page.
• Step 3: Customize your SBOM: Pick your format and decide which data fields and types of dependency information to include.
• Step 4: Decide how to distribute your SBOM. You can download and share it yourself, have FOSSA host it (and share the live URL), or distribute it via our SBOM Portal.

Ingesting and Analyzing Third-Party SBOMs (Available only for paid accounts)

FOSSA paid users can import, consolidate, and analyze third-party SBOMs in either SPDX or CycloneDX. Here's how:

• Step 1: Click the "Add Projects" button on the top right of your FOSSA dashboard. Then upload your SBOM with the "Import SBOM" option.
• Step 2: Add your JSON or XML SBOM file on the SBOM Upload page; bulk import is supported, so you can add multiple files at once
• Step 3: Once the upload process is complete, the SBOM will appear in your FOSSA projects list. From there, you can analyze it (review licenses and vulnerabilities, see remediation guidance, and so on) like you would your own project.