Quiero saber acerca de...

Federal Register / Vol. 86, No. 104 / Wednesday, June 2, 2021 / Notices documents, operational evidence, and support from broad-based constituencies in the software ecosystem.
Since 2018, NTIA has coordinated an open and transparent multistakeholder process on software component transparency, providing a forum in which a diverse and evolving set of experts and interested parties have been able to weigh in, share their leadership and respective visions, unpack the complex challenges of software supply chain, and propose various solutions.3
The idea of an SBOM is not new. Its roots lie in the concepts developed by noted American engineer and management consultant W. Edward Deming to build post-war industrial supply chain leadership, and over the last decade an SBOM has come to be considered vital to security by notable security experts.4 By providing a forum for SBOM discussions, NTIA has helped the community identify common themes, coalesce around standards, and emphasize interoperability. These discussions have led to the documentation of existing tools, products, and projects, and have helped drive further experimentation and implementation. With an emphasis on the practice of SBOM generation and use, NTIA has sought to facilitate proof-of-concept exercises in specific communities and sectors.5 NTIA has also worked across the federal government to share ideas about SBOM, seek feedback and engagement from experts in the civilian and national security community, and expand general awareness of SBOM.
What is an SBOM?

jbell on DSKJLSW7X2PROD with NOTICES

The Executive Order defines an SBOM as a formal record containing the details and supply chain relationships of various components used in building software. It refers to what the software assurance organization SAFECode calls third party components. Software is made and used by a wide range of organizations, but this diversity makes a single model for SBOM difficult. There is no one-size-fits-all approach to providing transparency for software assurance.
3 NTIA, Multistakeholder Process on Promoting Software Component Transparency, Notice of Open Meeting, 83 FR 26,434 June 7, 2018.
4 See Seth Carmody et al., Building Resilient Medical Technology Supply Chains with a Software Bill of Materials, 4 npj Digit. Med., at 1, 12 2021, https doi.org/10.1038/s41746-021-00403-w.
5 See Susan Miller, Protecting the Supply Chain with a Software Bill of Materials, GCN Feb. 22, 2021, https gcn.com/articles/2021/02/22/sbomsupply-chain-security.aspx.

VerDate Sep<11>2014

17:49 Jun 01, 2021

Jkt 253001

The Executive Order also defines SBOM in functional terms, framing its value in terms of use cases. It notes distinct but overlapping benefits that accrue to the organization that makes the software developers, the organization that chooses or buys software, and those that operate software. Many of these use case benefits center around tracking known or newly identified vulnerabilities, but SBOM can also support use cases around license management and software quality/efficiency, and can lay the foundation to detect software supply chain attacks. These benefits should serve as a lodestar for designing and publishing the minimum elements of an SBOM that can be applied across the diverse software ecosystem.
Potential Elements for an SBOM
NTIA proposes a definition of the minimum elements of an SBOM that builds on three broad, inter-related areas: Data fields, operational considerations, and support for automation. Focusing on these three elements will enable an evolving approach to software transparency, and serve to ensure that subsequent efforts will incorporate more detail or technical advances. The information below is preliminary, and the ultimate list published by NTIA will be revised based on public input.
Data fields. To understand the thirdparty components that make up software, certain data about each of those components should be tracked.
This baseline component information includes: 6
Supplier name Component name Version of the component Cryptograph hash of the component Any other unique identifier Dependency relationship Author of the SBOM data Some of these data fields could be expanded. For example, the dependency relationship generally refers to the idea that one component is included in another component, but could be expanded to also include referencing standards, which tools were used, or how software was compiled or built. Other data fields may need more clarity, including data fields for component and supplier name. As one SBOM document notes, component identification is fundamental to SBOM
and needs to scale globally across 6 See generally Framing Working Grp., Natl Telecomm. & Info. Admin., Framing Software Component Transparency 2019, https
www.ntia.gov/files/ntia/publications/framingsbom_
20191112.pdf providing further information on baseline components.

PO 00000

Frm 00024

Fmt 4703

Sfmt 4703

29569

diverse software ecosystems, sectors, and markets. 7 The challenge is that different technical communities and organizations have different approaches to determining software identity.
Operational considerations. SBOM is more than a set of data fields. Elements of SBOM include a set of operational and business decisions and actions that establish the practice of requesting, generating, sharing, and consuming SBOMs. This includes:
Frequency. Operational considerations touch on when and where the SBOM data is generated and tracked. SBOM data could be created and stored in the repository of the source. For built software, it can be tracked and assembled at the time of build. A new build or an update to the underlying source should, in turn, create a new SBOM.
Depth. The ideal SBOM should track dependencies, dependencies of those dependencies, and so on down to the complete graph of the assembled software. Complete depth may not always be feasible, especially as SBOM
practices are still novel in some communities. When an SBOM cannot convey the full set of transitive dependencies, it should explicitly acknowledge the known unknowns, so that the SBOM consumer can easily determine the difference between a component with no further dependencies and a component with unknown or partial dependencies.
Delivery. SBOMs should be available in a timely fashion to those who need them and have proper access permissions and roles in place. Sharing SBOM data down the supply chain can be thought of as comprising two parts:
How the existence and availability of the SBOM is made known advertisement or discovery and how the SBOM is retrieved by or transmitted to those who have the appropriate permissions access.8 Similar to other areas of software assurance, there will not be a one-size-fits-all approach.
Anyone offering SBOMs must have some mechanism to deliver them, 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 7 Framing Working Group, Natl Telecomm. &
Info. Admin., Software Identification Challenges and Guidance 2021, https www.ntia.gov/files/
ntia/publications/ntia_sbom_software_identity2021mar30.pdf.
8 Framing Working Grp., Natl Telecomm. & Info.
Admin., Sharing and Exchanging SBOMs 2021, https www.ntia.gov/files/ntia/publications/ntia_
sbom_sharing_exchanging_sboms-10feb2021.pdf.

E:FRFM02JNN1.SGM

02JNN1