On July 12, 2021, the U.S. Federal Government’s NTIA (National Telecommunications and Information Administration) published the minimum required elements for a software bill of materials. This list stems from the Biden Administration’s recent executive order on improving America’s cybersecurity, which includes a provision that requires any organization selling into the federal government to produce an SBOM.

The minimum requirements of a software bill of materials cover three categories. They are:

  • Data fields: Baseline information about each software component
  • Automation support: The ability to auto-generate SBOMs in machine- and human-readable formats
  • Practices and processes: How and when SBOMs should be generated and distributed

The intent of the required elements is to provide SBOM consumers with the information they need to manage vulnerabilities, inventory software components, and oversee license compliance. Read on for an overview of each category of required elements, including some helpful links and resources.

A Framework for Evaluating SBOM Tools - FOSSA
Customizability, ease of use, and support for CycloneDX and SPDX are among the most important features of a best-in-class SBOM tool.
Dependency HeavenFOSSA Editorial Team

SBOM Minimum Required Element: Data Fields

The minimum required elements of a software bill of materials include seven specific data fields. Per the NTIA, 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.”

The seven required data fields are as follows:

  • Supplier Name: The individual or organization that manufacturers a given software component.
  • Component Name: The name given to a unit of software. This is determined by the supplier.
  • Version of the Component: An identifier that specifies a change in software from a previous version. Again, this is determined by the supplier.
  • Other Unique Identifiers: Identifiers like Software Identification (SWID) Tags, Package Uniform Resource Locators (PURL), Common Platform Enumeration (CPE), or similar that would help SBOM consumers find components in key databases.
  • Dependency Relationship: A representation of how software components fit together; for example, that a certain upstream component is included in a certain piece of software.              
  • Author of SBOM Data: The entity that generates the SBOM metadata. This could be the software supplier, or it could be another individual/group.
  • Timestamp: The date and time when the software bill of materials is assembled.

SBOM Minimum Required Element: Automation Support

The next group of minimum requirements refers to the way SBOM data is communicated across the software ecosystem and from one organization to another. The goal of this requirement is to ensure SBOM data is actually usable — that it’s not only machine-readable but human-readable, and that it’s transmitted in formats that are interoperable. In practice, organizations tend to use a modern SBOM tool to ensure compliance with this requirement.

To achieve this objective, NTIA has identified three delivery formats for generating and consuming SBOMs. It’s critically important to note that organizations selling into the federal government must transmit SBOMs in one of these three formats to be compliant with the cybersecurity executive order.

The formats are:

Note: We at FOSSA (a software composition analysis solution that helps organizations manage risk in their use of open source software) support both CycloneDX and SPDX. Please reach out to our team directly for more information.

Software Package Data Exchange (SPDX)

SPDX is a standard data delivery format that captures key information related to provenance, licensing, and security. The current version 2.3 of SPDX, a project run by the Linux Foundation, supports the following file types:

CycloneDX

CycloneDX is a versatile bill of materials specification that serves a variety of security and licensing use cases. CycloneDX can be represented as XML files, JSON files, or Protocol Buffers.

The specification includes eight root elements:

  • Bill of Materials Metadata: Information on the application/product itself
  • Components: An inventory of proprietary and open source components
  • Services Information: External APIs that the software may call (along with endpoint URI’s, authentication requirements, and trust boundary traversals)
  • Dependencies: Both direct and transitive relationships
  • Compositions: Per CycloneDX’s website, this section describes “constituent parts (including components, services, and dependency relationships) and their completeness”
  • Vulnerabilities: This includes data like VEX, security advisories, and vulnerability details
  • Formulations: This refers to processes and steps in how something was produced or manufactured
  • Annotations: Annotations can be used to add context to the bill of materials

Software Identification (SWID) Tags

SWID tags are standardized XML formats that identify and contextualize the components of a software product. However, they have relatively limited utility compared to the full-stack CycloneDX and SDPDX specifications.

NIST has a helpful website that features several SWID resources, including:

SBOM Minimum Required Element: Practices and Processes

The final group of minimum required elements for a software bill of materials covers operational aspects of generating and requesting SBOMs. Specifically, the “Practices and Processes” section includes requirements in the following six areas:

  • Frequency: The NTIA mandates that organizations generate new SBOMs “if the software component is updated with a new build or release.” Additionally, suppliers should generate new SBOMs if they a) need to correct an error in the original version or b) learn new details about the software components.
  • Depth: Compliant SBOMs are required to include a) all top-level components, and b) all transitive dependencies. If an SBOM author is unable to include all transitive dependencies, they’re required to include enough information to where a consumer can find them recursively.
  • Known Unknowns: In cases where an SBOM author does not provide a full dependency graph, they are required to specify whether this is because a) the component has no further dependencies, or b) it’s unknown whether additional dependencies exist.
  • Distribution and Delivery: There are a few parts to this section, which is all about ensuring SBOMs are delivered quickly and in a digestible format. For one, SBOMs are required to be made available in a “timely” manner (although there is no set number of days or weeks). Next, they must have “appropriate” roles and access permissions in place. Finally, SBOMs can either be a) distributed with each instance of the product, or b) be made available in another accessible manner, such as a public website.
  • Access Control: If a supplier wants to limit SBOM data access to certain customers or users, they are required to provide terms of this access control. Additionally, the supplier would need to offer “specific allowances and accommodations” so that the SBOM consumer would be able to integrate the data into their security tools.
  • Accommodation of Mistakes: The cybersecurity executive order and regulations guiding SBOM creation are obviously new, so organizations are directed to be understanding of (unintentional) errors or omissions.

Generating a Software Bill of Materials with FOSSA

Along with the resources highlighted earlier in this blog, software composition analysis tools like FOSSA go a long way toward helping organizations build a software bill of materials. They:

  • Provide comprehensive and accurate data
  • Offer customizable reporting formats
  • Automate key steps in the SBOM creation process, saving teams significant time and strengthening software supply chain security

For more information on how FOSSA can help your organization build or update a software bill of materials, feel free to get in touch with our team.