The Minimum Elements For An Sbom
This document is abridged from
=this.source[0]
Main Points
- An SBOM must include all required fields.
- An SBOM must be in an approved format
- An SBOM must be timestamped and generated for every build or release
Scope
- Certain key points of the software supply chain discussion are out of scope of this report, including the question of regulatory and procurement requirements
- The “software” in the “Software Bill of Materials” naturally limits considerations of hardware. While software embedded in hardware and devices is certainly in scope, the key supply chain and security issue pertaining to hardware is distinct and complex enough to deserve its own treatment.
Minimum Elements
A piece of software can be represented as a hierarchical tree, made up of components that can, in turn, have subcomponents, and so on. Components are often “third party,” from another source, but might also be “first party,” that is, from the same supplier but able to be uniquely identified as a freestanding, trackable unit of software. Each component should have its own SBOM listing their components, building the hierarchical tree. The data fields apply to each component, which are, in turn, encoded with tools and formats for automation support following the defined practices and processes
Data Fields
The core of an SBOM is a consistent, uniform structure that captures and presents information used to understand the components that make up software. Data fields contain baseline information about each component that should be tracked and maintained. 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. This baseline component information includes
| Data Field | Description |
|---|---|
| Supplier Name | The name of an entity that creates, defines, and identifies components |
| Component Name | Designation assigned to a unit of software defined by the original supplier |
| Version of the Component | Identifier used by the supplier to specify a change in software from a previously identified version |
| Other Unique Identifiers | Other identifiers that are used to identify a component, or serve as a look-up key for relevant databases |
| Dependency Relationship | Characterizing the relationship that an upstream component X is included in software Y |
| Author of the SBOM Data | The name of the entity that creates the SBOM data for this component |
| Timestamp | Record of the date and time of the SBOM data assembly |
Automation Support
Support for automation, including automatic generation and machine-readability, allows the ability to scale across the software ecosystem, particularly across organizational boundaries.
The SBOM ==must== be conveyed across organizational boundaries in one of these interoperable formats; the data formats that are being used to generate and consume SBOMs are:
- Software Package Data eXchange (SPDX)
- CycloneDX13
- Software Identification (SWID) tags
Practices and Processes
Frequency
If the software component is updated with a new build or release, a new SBOM ==must== be created to reflect the new version of the software. This includes software builds to integrate an updated component or dependency. Similarly, if the supplier learns new details about the underlying components or wishes to correct an error in the existing SBOM data, the supplier should issue a new, revised SBOM.
Depth
An SBOM should contain all primary (top level) components, with all their transitive dependencies listed. At a minimum, all top-level dependencies ==must== be listed with enough detail to seek out the transitive dependencies recursively.
Going further into the graph will provide more information. As organizations begin SBOM, depth beyond the primary components may not be easily available due to existing requirements with subcomponent suppliers. Eventual adoption of SBOM processes will enable access to additional depth through deeper levels of transparency at the subcomponent level. It should be noted that some use cases require complete or mostly complete graphs, such as the ability to “prove the negative” that a given component is not on an organization’s network.
Known Unknowns
For instances in which the full dependency graph is not enumerated in the SBOM, the SBOM author ==must== explicitly identify “known unknowns.” That is, the dependency data draws a clear distinction between a component that has no further dependencies, and a component for which the presence of dependencies is unknown and incomplete. This must be integrated into the automated data. To avoid erroneous assumptions, the default interpretation of the data should be that the data is incomplete; the author of the data should affirmatively state when the direct dependencies of a component have been fully enumerated, or when a component has no further dependencies. Today, this is implemented in the dependency relationship data field.
Distribution and Delivery
SBOMs should be available in a timely fashion to those who need them and ==must== have appropriate access permissions and roles in place. The SBOM data can accompany each instance of the software, or merely be accessible and directly mappable to the specific version of the software in question (e.g. through a version-specific URL). Anyone offering SBOMs ==must== have some means to make them available and support ingestion, but this can ride on existing mechanisms. SBOM delivery can reflect the nature of the software as well: executables that live on endpoints can store the SBOM data on disk with the compiled code, whereas embedded systems or online services can have pointers to SBOM data stored online.
Access Control
If access control is desired, the terms ==must== be specified, including specific allowances and accommodations for integrating SBOM data into the user’s security tools. Such specification can be determined through licensing, contracts, or other existing mechanism used to circumscribe the use and rights around the software itself. Given the variation in software licensing and contracts, the nature of this specification is outside the scope of this document.
Accommodation of Mistakes
A final practice area, accommodation of mistakes, should be built into the initial implementation phase of SBOM, allowing for omissions and errors. As many commentators have observed, while internal management of supply chain data may be a best practice, it is still evolving. The Administration has identified SBOM as a priority to drive software assurance and supply chain risk management, and starting today is better than waiting for perfection. In light of the absence of perfection, consumers of SBOMs should be explicitly tolerant of the occasional incidental error. This will facilitate constant improvement of tools: suppliers should offer updated data as they come across issues with past SBOMs, and consumers should encourage these updates by welcoming supplements and corrections without penalty when offered in good faith. As stated above regarding frequency, when new data is known an updated SBOM should be issued. Notably, this tolerance should not apply to intentional obfuscation or willful ignorance.
Beyond Minimum Elements: Enabling Broader SBOM Use Cases
This section describes further additions and inclusions that can support broader SBOM use cases.
Recommended Data Fields
Hash of the Component
When referring to a piece of software, robust identifiers are important for mapping the existence of a component to relevant sources of data, such as vulnerability data sources. A cryptographic hash would provide a foundational element to assist in this mapping, as well as helping in instances of renaming and whitelisting.
Lifecycle Phase
The data about software components can be collected at different stages in the software lifecycle, including from the software source, at build time, or after build through a binary analysis tool. Due to unique features of each of these stages, the SBOM may have some differences depending on when and where the data was created.
In the short run, simply noting how this data was captured, (e.g. “source,” “build,” or “post-build”) will be helpful for consumption and data management.
Other Component Relationships
One approach that can be captured today beyond direct dependencies is “derivation” or “descendancy”. This can indicate that a component is similar to some other known component, but that some changes have been made.
License Information
License management was an early use case for SBOM, helping organizations with large and complex software portfolios track the licenses and terms of their diverse software components, especially for open source software.
Cloud-based Software and Software-as-a-Service
In the short run, it is recommended that cloud service providers assert that they have an internal SBOM. That SBOM must be maintained with the rough functional equivalents of the minimum elements above, although the exact format and architecture may vary based on a provider’s internal system.
The organization must also have the capability to act on this information and have a process to do so in a timely fashion.
SBOM Integrity and Authenticity
Those supplying and requesting SBOMs are encouraged to explore options to both sign SBOMs and verify tamper-detection.
Vulnerabilities and SBOM
It is recommended that vulnerability data be tracked in separate data structures from the SBOM.
Vulnerability and Exploitability in Dependencies
In the SBOM context, focusing on upstream vulnerable components that have been deemed not to have an impact on the downstream software will waste time and resources, without offering immediate security benefits. Addressing this challenge requires two steps.
First, the supplier must make some reliable determination that a vulnerability does not affect a specific piece of software.
The second step requires communication downstream to the next user of this SBOM data, asserting that the vulnerability does not put the organization at risk. This is straightforward, linking of a piece of software (the vulnerability in question) and the status of that vulnerability. The community refers to this as a “Vulnerability Exploitability eXchange,” or VEX.
The core of VEX is the communication of whether or not a given piece software is “affected” by a given vulnerability. It is recommended that tools that analyze SBOM data for the customer build in the capability to automatically incorporate VEX data.
VEX is being implemented today as a profile in the [[Common Security Advisory Framework]].
Legacy Software and Binary Analysis
There is a key difference in how SBOMs are generated from a source repository, at the point of the building of the software, and for already-built software. While there are many unique circumstances, those requesting SBOM data should try to obtain it from the instance of the build since the instance of the build captures the details of the software as built, including reflecting any changes made by the compiler or other tools.
Flexibility vs Uniformity in Implementation
All requirements built on the minimum elements should draw from two key concepts. First, all security, especially SBOM, is a process and not a single goal. Second, the fundamental principle behind SBOM is the power of transparency, and any rules or guidance should focus on enabling the use cases described in this document and elsewhere.
Future SBOM Work
As this document has tried to emphasize, SBOM is an emerging technology and practice. Organizations are implementing SBOM today, but there is much more to do. It is important to stress that SBOM will not solve all security or supply chain attacks. Effectively using this data requires automation, and automation requires the potential for both automated consumption and policy enforcement.
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.
- https://www.ntia.gov/files/ntia/publications/sbom_minimum_elements_report.pdf
- https://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/