SBOMs (software bill of materials) are inventories of all software components (proprietary and open source), open source licenses, and dependencies in a given product. An SBOM provides visibility into the software supply chain and any license compliance, security, and quality risks that may exist.

SBOMs have become increasingly relevant and valuable in light of the fact that today's applications are generally built with many individual software components, often from a variety of open source and proprietary source packages. Given these complexities, it can be difficult for organizations and individuals involved with the product (manufacturers, operators, buyers) to have full visibility into the software supply chain and supply chain risks.

By providing key insights in these areas, SBOMs help organizations quickly identify and remediate potential security vulnerabilities, fulfill licensing requirements, and apply version control best practices. Additionally, the Biden Administration's 2021 cybersecurity executive order includes a provision that mandates SBOM creation (for organizations that sell into the federal government), further elevating their importance.

In this blog, we’ll explore a variety of topics related to a software bill of materials, including SBOM formats, benefits, and required elements.

SBOM Elements

On July 12, 2021, the U.S. federal government published the minimum required elements of a software bill of materials (for the purposes of compliance with the Biden Administration's executive order). These guidelines apply only to organizations that conduct business with the federal government, but we wouldn't be surprised if organizations of all types move to adopt them.

These minimum elements of an SBOM are grouped into three areas:

  • Data fields
  • Automation support
  • Practices and processes

We'll take a closer look at each of these elements in the sections below

Data Fields

The data field category includes information that describes the components that comprise a piece of software. Per the U.S. NTIA (National Telecommunications and Information Administration), the agency which published the SBOM minimum requirements, the intent of the data fields is as follows:

The goal of these fields is to enable sufficient identification of these components to track them across the software supply chain and map them to other beneficial sources of data, such as vulnerability databases or license databases.

They are:

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

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

Automation Support

Organizations looking to closely and continuously track SBOM component data will need that data to be presented in consistent and digestible formats. The "Automation Support" section of the SBOM minimum requirements addresses this matter. It identifies three reporting formats that organizations must choose from when they transmit SBOMs across organizational boundaries. They are:

We will discuss these reporting formats in more detail later in this blog, but the NTIA selected them because each is human-readable, machine-readable, and "interoperable for the core data fields and use common data syntax representations."

Practices and Processes

Finally, the "Practices and Processes" section includes six requirements in areas related to how and when SBOMs should be updated and delivered. They are:

  • Frequency: New SBOMs must be created if the software component is updated with a new build or release.
  • Depth: SBOM authors should include both top-level components and their transitive dependencies.
  • Known Unknowns: In situations where the SBOM doesn't include a full dependency graph, the SBOM author should note whether this is because a) the component has no further dependencies, or b) the "presence of dependencies is unknown and incomplete."
  • Distribution and Delivery: SBOMs must be made available in a "timely" fashion — with "appropriate access permissions and roles in place."
  • Access Control: Organizations seeking to keep certain elements of a software bill of materials private are required to specify the terms of access control, "including specific allowances and accommodations for integrating SBOM data into the user’s security tools."
  • Accommodation of Mistakes: The regulations governing SBOM creation are obviously quite new, so SBOM consumers are directed to be tolerant of  (unintentional) errors or omissions.
Watch On-Demand: Understanding and Using CycloneDX

SBOM Formats

The most popular SBOM formats that are both human- and machine-readable are SPDX (Software Package Data Exchange) and CycloneDX. As mentioned, these are both highlighted in the U.S. government's cybersecurity executive order. 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 this format isn't nearly as comprehensive (or commonly used) as SPDX and CycloneDX.

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.

SPDX

SPDX, a project run by the Linux Foundation, aims to standardize the way organizations share and consume information found in a software bill of materials. SPDX captures data related to provenance, licensing, and security. The image below outlines what data can be found in an SPDX document.

SPDX specification description
Image via SPDX website

CycloneDX

Cyclone DX is a comprehensive SBOM format with roots in application security but a wide range of use cases. The standard consists of six elements:

  • Bill of Materials Metadata: Information on the application/product itself — the supplier, manufacturer, component the SBOM describes, and any tools used to compile an SBOM
  • Components: A complete inventory of proprietary and open source components, including licensing information
  • Services: External APIs that the software may call along with endpoint URIs, authentication requirements, and trust boundary traversals
  • Dependencies: Both direct and transitive relationships
  • Vulnerabilities: CycloneDX can describe several types of vulnerability data, including severity score and VEX (Vulnerability Exploitability eXchange).
  • ‍Compositions: This element is used to communicate the completeness of  your description of BOM elements

SWID Tags

A Software Identification Tag (or “SWID” for short) is a standardized XML format that identifies and contextualizes the components of a software product. There are four types of SWID tags that come into play at different points in the software development lifecycle (SDLC).

  • Corpus Tags: These identify and describe software components in a pre-installation state. Per NIST, corpus tags are “intended to be used as inputs to software installation tools and processes.”
  • Primary Tags: The intent of a primary tag is to identify and contextualize software products post-installation.
  • Patch Tags: As the name implies, patch tags identify and describe the patch (as opposed to the core product itself). Additionally, patch tags can and do include contextual information on the relationship between the patch and other products or patches.
  • Supplemental Tags: The SWID format allows only tag creators to modify corpus, primary, and patch tags. Supplemental tags give software users and software management tools the ability to add helpful contextual information of local utility, such as license keys and contact information for relevant parties.

Organizations have some measure of flexibility when it comes to deciding which tags and specific data elements to include with their products. The SWID specification outlines a number of optional elements and attributes in addition to several required fields.

Ultimately, a minimal valid and conforming tag requires only a handful of elements that describe the software product (such as name and Tag ID) and the entity that created it. For the most comprehensive and up-to-date information on SWID Tag data elements, we recommend viewing the full ISO/IEC 19770-2:2015 Standard.

SBOM Benefits

The large number of different software components, dependencies, and licenses that are part of modern applications means managing them can be quite difficult. Without an SBOM, processes like conducting a risk assessment, doing due diligence around OSS license compliance (like identifying copyleft-licensed components), and remediating vulnerabilities can be incredibly time-consuming and painful.

The flip side of this, of course, is that a software bill of materials can go a long way toward managing risks in the software supply chain. Specifically, SBOMs help:

  • Achieve compliance with government regulations
  • Accelerate the process of identifying and remediating potential vulnerabilities
  • Enable manufacturers to meet attribution requirements that come with the use of many open source libraries
  • Reduce unnecessary work that could fall on development teams due to ambiguous supply chains
  • Provide transparency and build trust with consumers
  • Make it easier for manufacturers to identify and address a broken component post-release
  • Avoid significant business disruption in the event of an audit

SBOM Use Cases

Clearly, there are many compelling reasons why organizations might look to create a software bill of materials. So, it’s recommended that organizations always create SBOMs for all products (and update them for any new release).

With that said, there are a few specific SBOM use cases that may prove particularly valuable.

Fundraising, M&A, and IPO: A software bill of materials is an important part of the technical due diligence process that comes with a potential merger or acquisition, IPO, or fundraising round. Interested parties may request documentation to better understand the software components — and any license compliance, security, or code quality risks — within your products.  

Regulatory Compliance: As mentioned, the Biden Administration's  cybersecurity executive order on software supply chain security requires organizations that sell into the federal government to publish an SBOM with each product or as part of a public website.

Customer Requests: As preventing software supply chain attacks becomes an increasingly high priority for organizations across the globe, we expect more and more enterprises to require SBOMs as part of the purchasing and/or renewal processes.

Backward Compatibility: Companies that maintain a large volume of old software are often required to make OSS package updates and upgrades. Of course, it’s much easier to do this with a comprehensive inventory of the OSS in those legacy products.

Tools to Help Generate and Manage SBOMs

It's safe to assume a software bill of materials will play an increasingly important role in the way business is conducted. But given the volume of data required to craft an SBOM, putting the pieces together via manual processes alone can be quite challenging.

Software composition analysis tools like FOSSA go a long way toward helping organizations build and manage SBOMs. They:

  • Provide comprehensive and accurate data
  • Offer customizable reporting formats
  • Automate key steps in the SBOM creation and management process, saving teams significant time

For more information on how FOSSA's SBOM tools can help your organization, feel free to get in touch with our team.