The project to define and publish a national standard for Software Bill of Materials (SBOM) was initiated by the NTIA/National Telecommunications and Information Administration and is currently the responsibility of the CISA/Cybersecurity & Infrastructure Security Agency. The implementation of SBOMs is referenced multiple times in President Biden’s “Executive Order on Improving the Nation’s Cybersecurity” of March 12, 2021.
Software Bill of Materials as a Governmental Mandate
In Section 10 (j) of the directive we have the following definition/description:
the term “Software Bill of Materials” or “SBOM” means a formal record containing the details and supply chain relationships of various components used in building software. Software developers and vendors often create products by assembling existing open source and commercial software components. The SBOM enumerates these components in a product. It is analogous to a list of ingredients on food packaging. An SBOM is useful to those who develop or manufacture software, those who select or purchase software, and those who operate software. Developers often use available open source and third-party software components to create a product; an SBOM allows the builder to make sure those components are up to date and to respond quickly to new vulnerabilities. Buyers can use an SBOM to perform vulnerability or license analysis, both of which can be used to evaluate risk in a product. Those who operate software can use SBOMs to quickly and easily determine whether they are at potential risk of a newly discovered vulnerability. A widely used, machine-readable SBOM format allows for greater benefits through automation and tool integration. The SBOMs gain greater value when collectively stored in a repository that can be easily queried by other applications and systems. Understanding the supply chain of software, obtaining an SBOM, and using it to analyze known vulnerabilities are crucial in managing risk.
The actual directive from Section 4 (e) (vii) is:
Within 90 days of publication of the preliminary guidelines pursuant to subsection (c) of this section, the Secretary of Commerce acting through the Director of NIST, in consultation with the heads of such agencies as the Director of NIST deems appropriate, shall issue guidance identifying practices that enhance the security of the software supply chain. Such guidance may incorporate the guidelines published pursuant to subsections (c) and (i) of this section. Such guidance shall include standards, procedures, or criteria regarding:
…(vii) providing a purchaser a Software Bill of Materials (SBOM) for each product directly or by publishing it on a public website;
The immediate impact is that large companies will need to produce an SBOM for any software supplied to any U.S. government agency sometime in 2022. There are many details to be worked out, but we have never seen anything that will raise the urgency for Software Composition Analysis like this.
Format Specifications for Software Bill of Materials
The NTIA SBOM Standards and Formats Working Group is an open organization that is working to define and publish SBOM format specifications. The current specification allows for three (3) standard formats:
- SPDX (open)
- CycloneDX (open)
- SWID (proprietary)
The three standards have different strengths and weaknesses, and the Working Group is promoting the creation and testing of tools that translate one format to another. This approach has limitations, because different formats include data elements that are not provided by the other formats.
For example, the SPDX specification explicitly supports component relationships, but the CycloneDX specification does not. Nevertheless, translation (or some form or reconciliation) is critical. The point of an SBOM is to communicate critical details from the organization that distributes a software product to any organization receiving that software product.
Given the inherent size and complexity of a typical SBOM, this will require all organizations to use tools that automate both the creation and consumption of an SBOM. This is so that the “downstream” receiving organization can efficiently incorporate data from an “upstream” product or FOSS project into their SCA data.
Here are some additional online resources of SBOM:
- Survey of Existing SBOM Formats and Standards from the National Telecommunications and Information Administration’s working group on Software Component Transparency
Using Software Composition Analysis for Software Bill of Materials
The primary focus of the Presidential Directive is cybersecurity and therefore the current focus for SBOMs is on vulnerabilities. But the Directive also says, “Buyers can use an SBOM to perform vulnerability or license analysis, both of which can be used to evaluate risk in a product.” In general, it seems obvious that defining, producing or consuming SBOMs are part of Software Composition Analysis (SCA).
There is no canonical definition of SCA – each software company in our market offers its own definition so we will do the same. From our perspective, Software Composition Analysis is a set of processes and tools that cover:
- Identification – Identify distinct “units” of third-party software used in a product or project and their provenance
- Licensing – Determine the licensing for each software unit
- Security – Identify known security vulnerabilities for each software unit
- Quality – Evaluate the quality of a software unit based on software development data, such as number of bugs, fixes, etc.
Even before the Presidential Directive, the primary market focus for SCA solutions has been on security vulnerabilities because of the reasonable perception that security vulnerabilities are the greatest risk.
Most SCA solution providers define F(OSS) as the target for SCA. nexB’s approach is that SCA applies to all third-party software including commercial/proprietary software. In the long run, it is useful to apply SCA to first-party software for completeness.
nexB is a market leader in Identification and Licensing from the scanning perspective. With very strong capabilities from scanning for the first two areas, we are building matching capabilities (MatchCode) to complete our solution. This is because matching typically requires much less human/expert work at the point of analysis.
We have an emerging solution for Security with VulnerableCode. And we plan to use third-party solutions like GrimoireLabs for the Quality area.
Security and Licensing for Software Bill of Materials
As we move into the Security area, it is important to understand a critical “temporal shift” between Licensing and Security data for SCA and SBOMs.
Licensing requires investigating historical data to determine the license(s) for a software unit. This comes with the reasonable expectation that the license is reasonably stable over time, so it makes sense to store the license data in a local database. Also, you can usually record your data at the “summary” level of a component or package for fulfillment of Attribution or Redistribution obligations.
For Security, there are current known (and unknown) vulnerabilities where the data is extremely fluid in terms of identifying the vulnerabilities, how they apply to your product and how and when a vulnerability patch is available. This data may be at a component or package level, but it is so fluid that it does not make sense to rely on a local database except for recording your vulnerability remediation work.
In both cases, it is clear that the only viable SCA solutions will be highly automated to cope with the continued exponential increase in the number of FOSS packages and components.
SPDX and nexB
The Software Package Data Exchange (SPDX®) specification is an ISO/IEC standard for communicating SBOM information. Representatives of nexB were founding members of the SPDX working group, sponsored by the Linux Foundation. nexB is committed to participating actively in the SPDX standard.
Specific support for SPDX in nexB’s open compliance solution DejaCode includes the cross-reference of DejaCode License definitions with the SPDX License List via the SPDX Short Identifier and a corresponding link.
Specific support for SPDX is also provided by the open source projects of the nexB-sponsored AboutCode organization, including:
- A ScanCode Toolkit output option that creates a file in SPDX v2.2 format from scan results.
- Cross-reference to the SPDX Short Identifier from each license in the ScanCode LicenseDB. The LicenseDB uses the
LicenseRefnotation defined by SPDX to provide an SPDX-compliant license identifier for those licenses in the LicenseDB list that are not in the SPDX license list.
Work-in-Progress
The NTIA SBOM specification is still in the process of finalization by the working group, which is expected to happen in 2022. The promotion of this standard by the USA federal government is expected to lead to widespread adoption by software suppliers. This will likely become a requirement mandated by major software consumers.
To learn more about Software Composition Analysis and SBOMs, watch this recorded webinar on leveraging SCA for Software Supply Chain Security.
