Yesterday, the United States Department of Commerce released The Minimum Elements for a Software Bill of Materials (SBOM), in accordance with President Biden Executive Order 14028 on Improving the Nation’s Cybersecurity. For those who have been following the National Telecommunications and Information Administration (NTIA) SBOM work, you won’t find any surprises in the release. The document thoroughly describes the SBOM, provides motivation for the SBOM as a standard security document, and makes the point that the SBOM is only one piece of an effective security ecosystem.
Data Fields
The suggested baseline data fields of the SBOM should provide sufficient information about the components of the SBOM to enable further investigation into associated information about the components, including vulnerabilities. The document suggests the following minimum elements:
Supplier Name – the name of the entity that creates, defines, and identifies components, for example, Microsoft
Component Name – designation assigned to a unit of software defined by the original supplier, for example, Windows 10
Version of the Component – identifier used by the supplier to specify a change in software from a previously identified version, for example, version 1607
Other Unique Identifiers – other identifiers that are used to identify a component, or serve as a look-up key for relevant databases, including the Common Platform Enumeration (CPE) that can be used to find vulnerabilities for the component in the National Vulnerability Database (NVD), for example, cpe:2.3:o:Microsoft:windows_10:1607:*:*:*:*:*:x64:*
Dependency Relationship – characterizing the relationship that an upstream component X is included in software Y, for example Notepad is included in Windows 10 version 1607
Author of SBOM data – the name of the entity that creates the SBOM data for this component, for example, Vigilant Ops
Timestamp – record of the date and time of the SBOM data assembly, for example, 7-JUL-21 09:15
Data Fields Comments and Key Points
Given that a function of the baseline information contained in the data fields of a component is to enable discovery of additional sources of information about that component, such as vulnerabilities, the document acknowledges some inherent gaps and issues.
The supplier name and component name may or may not be leveraged to uniquely identify a component, as there are likely multiple versions in use. For example, Microsoft Windows 10 could also be referred to as MS Win 10. This is not a shortcoming of the SBOM, but rather a longstanding problem in the world of software. The document recommends that the naming task be left up to “A decentralized model, where suppliers identify and manage their own software namespace…”. The negative consequences of this approach are illustrated in the monumental effort needed to manually search and match component information with Common Platform Enumeration (CPE) information.
In addition, the document acknowledges that the dependency relationship information will be challenging to collect and include, due to “…existing requirements with subcomponent suppliers.” Eventually, as SBOM becomes integrated into the software supply chain, subcomponent information will be available. At the outset, however, depth beyond the top-level components is not likely. In this case, the document recommends that the SBOM identify these “known unknowns” to differentiate between components for which no dependencies exist and those for which the dependencies are unknown.
Automation Support
There are three data formats suggested as standards to support the generation and consumption of the SBOM:
- Software Package Data eXchange (SPDX)
- CycloneDX
- Software Identification (SWID) tags
According to the document, “The SBOM must be conveyed across organizational boundaries in one of these formats.”
Practices and Processes
To integrate the SBOM into a secure software development lifecycle, the document calls out a number of elements that organizations will need to address.
Frequency – at a minimum, new software builds, or releases require that a new SBOM be created. In addition, new information about components or errors in existing SBOMs can also trigger the creation of a new SBOM.
Depth – an SBOM should contain all primary (top-level) components with their dependent components, but an SBOM must contain primary (top-level) components with enough detail to “…seek out the transitive dependencies recursively.” This statement is another acknowledgement of the problem of including dependency relationship as a baseline data field.
Known Unknowns – the SBOM author must explicitly include information in the dependency relationship field to indicate that either there are no further dependencies for the given component or the dependencies for the given component are unknown. IMPORTANT NOTE – “To avoid erroneous assumptions, the default interpretation of the data should be that the data is incomplete…”
Distribution and Delivery – the SBOM should be made available in a timely fashion, and appropriate access permissions must be in place to protect the contents of the SBOM. The document suggests that the distribution and delivery of the SBOM will not be a “one-size-fits-all” approach but acknowledges that SBOM producers must have a way to make them available to SBOM consumers.
Access Control – in the cases where access control is desired by the producers of the SBOM, the terms must be specified, however the details of this specification are “…outside the scope of this document”.
Accommodation of Mistakes – the document allows that the initial implementation of the SBOM will not be perfect, so consumers of the SBOM should be “…tolerant of the occasional incidental error.” SBOM producers should be encouraged to share updates and corrections to SBOMs “…without penalty when offered in good faith.” These updates or corrections should trigger the creation of a new SBOM, as mentioned in the Frequency discussion above.
Beyond Minimum Elements
The document addresses additional inclusions that “…expand transparency in the software supply chain…”, however we will not detail those in this summary, except for the section on Vulnerabilities. It is recommended that the actual document be reviewed for additional details about the other sections.
Vulnerabilities and SBOM
The document acknowledges that the primary use case for SBOM is “…to identify known vulnerabilities and risks in the software supply chain.” The document then goes on to describe that the data contained in an SBOM is primarily static, while vulnerability information related to the SBOM data is dynamic. This seeming conflict, however, “…does not limit the value of providing vulnerability, software weaknesses, and risk information to the consumer of the software…”
Vulnerability and Exploitability in Dependencies
While it is true that not all sub-component vulnerabilities create risk in the component, as the document points out, this determination requires analysis by the SBOM producer to reach a reliable conclusion regarding vulnerability impact. To avoid unnecessary concern from the SBOM consumer, the SBOM producer should have an efficient way to communicate the vulnerability impact. The document refers to the term Vulnerability Exploitability eXchange (VEX) as the “…communication of whether or not a given piece of software is affected by a given vulnerability.” The document recommends including this VEX information in the SBOM analysis.
Summary
“Ultimately, SBOM should not be seen as a unique security phenomenon, but yet another practice that can support the broader effort to secure the supply chain.” In keeping with Executive Order 14028, The Minimum Elements for a Software Bill of Materials (SBOM) provides input to the next step of developing specific SBOM guidance. It is recommended that the “…Federal Government should encourage or develop resources on how to implement SBOMs, potentially involving sector-specific or technology-specific details.”
Clearly, the SBOM ecosystem is continuing to evolve, but it is encouraging that the Federal Government decided to act now versus waiting to get it perfected.
Ken Zalevsky
ken.zalevsky@vigilant-ops.com
412-704-4600
