Building secure software products or applications in this age requires a full knowledge of the exact components of the application you’re building. The dependencies, licenses, files, and other assets that make up your software package are potential points of vulnerability through which malicious actors can launch an attack on your software and other applications down the line on the supply chain.
As part of the efforts to combat the recent increase in the frequency and impact of attacks on software supply chains, the Federal Government in coordination with the NTIA issued an executive order that detailed various measures to improve cybersecurity and guarantee the integrity of third-party components used in software packages. One such measure is the Software Bill of Materials.
This is a formal document that contains all the components of a software package and the supply chain relationships between these components. Preparing a comprehensive Software Bill of Material is not just standard practice, it is also required by law. This post defines the scope of the Software Bill of Materials and the minimum elements that must be included in a comprehensive bill of materials.
What Does NTIA’s Minimum Components of an SBOM Provide?
The SBOM serves as a formal guide for companies that build, purchase or operate software, providing all the information they need to enhance their understanding of the software supply chain. It also helps to easily track down emerging vulnerabilities should they occur, and reduce software supply chain risks. However, for the SBOM to meet the stipulated requirements of the Federal Government, there are some basic elements that it should contain. These elements are often classified into three categories:
- Data fields: An SBOM is expected to provide important data about software components such as the name of the component, the name of the supplier, the software version, and other unique identifiers. It should also detail the relationships between dependencies. This data makes it possible to accurately identify all software components and track them down across the software supply chain.
- Automation support: The Software Bill of Materials should be machine-readable and also capable of automatic generation. This allows continuous tracking of data included in the SBOM. Usually, these documents are in standard formats such as SPDX, CycloneDX, and SWID tags and this makes them human readable as well.
- Practices and processes: SBOM documentation is also expected to detail the standard practices and processes for preparing and updating the SBOM. It should also include practices for distributing and accessing the SBOM as well as measures for handling incidental errors.
NTIA’s minimum required elements of SBOM documentation provide a clear criterion of what is expected in an SBOM guideline for the basic use cases of your Software Bill of Materials such as managing vulnerabilities, taking an inventory of software components, and managing software licenses. The framework is being updated and may include additional elements that extend its usability in the nearest future. In the subsequent sections of this page, we will explain these key components of your Software Bill of Materials in greater detail. The minimum required elements of a Software Bill of Materials include seven data fields as specified below.
Data Fields: Minimum Requirements
The purpose of the Software Bill of Materials is to provide information that helps users and other stakeholders easily identify software components. Expectedly, one of the first and most important elements of the SBOM is the data that should be included for every component detailed in the document. In addition to aiding in the identification of individual components, the data also makes it easier to track the components across the various places they’re used in the software supply chain.
- Supplier Name: The supplier is the originator or manufacturer of the software component in question. This is the name of the individual or organization that creates, defines, and identifies the software components.
- Component Name: This refers to the designated name assigned to the software as defined by the original supplier or manufacturer. In cases where there are multiple names and aliases for the software, they may be noted as well.
- Component Version: The SBOM should include the release number or category number as specified by the supplier or manufacturer. The version data serves as an identifier that specifies any change in the software from a previously identified version of the subsequent release of the software.
- Other Unique Identifiers: This refers to additional identifiers other than the component name and version. These additional identifiers provide an additional layer of identification for the component and can also be used as a lookup key to find the component in relevant databases.
- Dependency Relationship: This is one of the most important data components of a Software Bill of Materials, since the SBOM is meant to detail how software components fit together. The dependency relationship specifies the relationship between software X used within your application and its upstream components.
- Author of SBOM Data: This refers to the individual that created the SBOM data. Sometimes, the software supplier may also double as the author. However, in many cases, the author is another individual or group.
Automation Support: Minimum Requirements
The use of the Software Bill of Materials often cuts across organizational boundaries. This means the data contained in the SBOM is often used by multiple departments within an organization and by several organizations as well. To ensure the ease of use of this documentation, the NTIA recommends that the SBOM should be in a format that is both machine-readable and human-readable. Preparing and transmitting the SBOM in standard automated formats like this improves the interoperability of this document for its various intended purposes.
The NTIA recognizes three delivery formats for generating and transmitting SBOMs. Your Software Bill of Material should match any of these formats to be compliant with the standards laid down by the government’s cybersecurity executive order. These standard formats include:
- Software Package Data Exchange (SPDX)
- Software Identification (SWID) Tags
- CycloneDX
Software Package Data Exchange (SPDX)
The SPDX is an open standard for delivering SBOM data. It captures important information about the software including its components, provenance, licenses, and copyrights. It also provides security references. The SPDX version 2.2 is the most recent version and it supports the YAML 1.2 file type, JavaScript Object Notation, and Resource Description Framework (RDF/XML). tag: value flat text file and .xls spreadsheets
Software Identification (SWID) Tags
SWID tags are designed to help identify and contextualize the components of any software product. The Software Identification tags project (SWID Tags) is a set of tools for generating and validating the identification tags of a piece of software. These Java-based tools support XML SWID tags based on the standardized format as defined by the ISO/IEC 19770-2:2015, and Concise Binary Object Representation (CBOR). The NIST has a website with a list of helpful resources for:
- Building SWID and CoSWID tags
- Validating SWID and CoSWID tags based on specific schema requirements and best-practice guidelines
- A web app that provides SWID tag validation service which can be deployed to a Java application server
- SWID repo client for posting tags to the National Vulnerability Database
CycloneDX
CycloneDX claims to be a “lightweight Software Bill of Materials (SBOM) standard.” It is useful for supply chain component analysis and application security. Organizations that adopt CycloneDX can seamlessly meet the minimum SBOM requirements and mature into more sophisticated use cases of the SBOM documentation over time.
CycloneDX SBOMs are typically presented in XML, JSON, or Protocol Buffers formats. The specification often includes these five fields:
- The Bill of Materials Metadata: This includes the general information about the application or software product itself.
- Components: This is a comprehensive inventory that covers all the proprietary and open-source components of the software.
- Services Information: This details all the External APIs that the application is likely to call during its operation. It includes all the endpoint URLs, authentication requirements, and trust boundary traversals.
- Dependencies: The documentation also details all the components and services within the Software package. This includes both direct and transitive relationships.
- Compositions: This refers to the completeness of all the constituent parts including the individual components, services, and dependency relationships. Each composition is typically described in terms of whether they’re complete, incomplete, incomplete first-party only, incomplete third-party only, or completely unknown.
Practices and Processes: Minimum Requirements
The final element of your Software Bill of Material focuses on the mechanics of the SBOM use itself. The practices and processes cover the operational details of generating and using the SBOM and must be included in any policy, or contract that requests it. The following are the key requirements that must be detailed in the Practices and Processes section of your Software Bill of Materials:
- Frequency: This section details how often an organization has to generate new Software Bill for Materials. Generally, the NTIA recommends that you generate a new SBOM anytime your software component is updated or a new version is released. Suppliers are also expected to generate new SBOMs whenever they find an error in the original version or learn new details about the components of their software that were not included in the initial documentation.
- Depth: The depth of your SBOM depends on what’s included in the document. In order to be compliant, your SBOM is expected to include all top-level components and all transitive dependencies. In situations where the author is unable to include all the transitive dependencies, the document should instruct the consumer on where they can find them.
- There are instances where the SBOM author cannot provide a full dependency graph for one reason or another. This may be because the component has no further dependencies or they do not know whether these dependencies exist or not. The SBOM author is required to specify this reason.
- Distribution and Delivery: The goal of this requirement is to ensure that SBOMs are delivered quickly and in an easily digestible format. Although this requirement does not specify the number of days or weeks by which SBOMs are meant to be delivered, they should be turned in as quickly as possible. Also, the SBOM should have appropriate roles and access permissions set in place when it is delivered. Finally, the requirement stipulates that the SBOM can either be distributed with each instance of the product or be made available in any other easily accessible manner such as via a public website.
- Access Control: In cases where the supplier decides to limit access to the SBOM data to specific users or customers, the author is required to specify the terms of access control. There’s also a need to offer specific allowances for consumers that would like to integrate the SBOM data into their own security tools.
- Accommodation of Mistakes: SBOM can help improve software assurance and software supply chain risk management. However, it is still far from perfect. Thus, consumers need to be tolerant of the occasional unintentional errors or omissions that may occur in preparing SBOMs.
Thinking Beyond NTIA’s Minimum Requirements
So far, we have discussed the minimum elements that are required in your Software Bill of Materials. These minimum elements represent the recommended requirements, especially for the most basic use cases of this documentation. While they lay a good foundation for software provenance and security, one must look beyond these requirements. The following are some recommendations to consider for more advanced SBOM use cases.
Additional Data Fields
In addition to the data fields covered in the minimum requirements document, there are additional data fields that are recommended for instances where a higher level of security is necessary. Some of these additional data fields include:
- A cryptographic hash of the software components
- Software lifecycle phase data
- Relationships between other components
- License information
Cloud-based Software and Software-as-a-Service
Another potential area where the SBOM requirements may go beyond the basics is in managing Software-as-a-Service (SaaS) products. These types of software products have unique challenges as far as SBOM data is concerned. To start with, the security risks in the cloud context are unique. Also, the responsibility for handling those risks lies with the service provider. Preparing SBOM documentation for cloud-based software is also more complex since they tend to have a shorter release cycle.
SBOM Integrity and Authenticity
Another likely issue that’s worth noting is the process of authenticating the source of SBOM data itself. Currently, signatures and public key infrastructure are the go-to solutions for verifying the integrity of software in today’s digital world. Authors and suppliers of SBOMs may need to leverage these existing software signatures to improve the reliability of SBOM data.
Vulnerability and Exploitability in Dependencies
Although the purpose of SBOMs is to make it easier to detect vulnerabilities, it is important to note that not all vulnerabilities in dependencies constitute major risks for software that rely on them. To avoid wasting time and resources, software suppliers will need to put measures in place to determine the potential impacts of a dependency vulnerability on software that uses downstream and communicate the risk level (or lack of it in this case) to the users of the SBOM data downstream.
Flexibility vs. Uniformity in Implementation
Whenever software security is being discussed, the question of flexibility and uniformity always comes to the fore. This applies to advanced use cases of SBOMs too. To successfully implement SBOMs there will be a need for broad policies that apply to all areas as well as specific cases where flexibility will be necessary.