Voglio sapere a riguardo di…

29570

Federal Register / Vol. 86, No. 104 / Wednesday, June 2, 2021 / Notices
services can have pointers to SBOM
data stored online.
Automation support. A key element for SBOM to scale across the software ecosystem, particularly across organizational boundaries, is support for automation, including automatic generation and machine-readability. As the Executive Order notes, SBOMs should be machine-readable and should allow for greater benefits through automation and tool integration.
Manual entry or distribution with spreadsheets does not scale, especially across organizations.
The SBOM community has identified three existing data standards formats that can convey the data fields and be used to support the operations described above: SPDX,9 CycloneDX,10
and SWID tags.11 Experts in these formats have mapped between them to create interoperability for the baseline described above. Because these formats already are subject to public input and translation tools exist, they serve as logical starting points for sharing basic data.12
In addition to the three SBOM
formats, the need for automation defines how some of the fields might be implemented better. For instance, machine-scale detection of vulnerabilities requires mapping component identity fields to existing vulnerability databases.

jbell on DSKJLSW7X2PROD with NOTICES

Request for Comment The discussion above lays out the collected data points and experience from experts and practitioners in SBOM, including existing practices and novel proof-of-concept work. To inform, validate, and update NTIAs understanding of SBOM, NTIA seeks comment on the following questions:
1. Are the elements described above, including data fields, operational considerations, and support for automation, sufficient? What other elements should be considered and why?
2. Are there additional use cases that can further inform the elements of SBOM?
3. SBOM creation and use touches on a number of related areas in IT
9 See also SPDX, https spdx.dev/ last visited May 18, 2021.
10 See also CycloneDX, https cyclonedx.org/
last visited May 18, 2021.
11 See David Waltermire et al., Guidelines for the Creation of Interoperable Software Identification SWID Tags 2016 Natl Inst. of Standards & Tech.
Internal Rep. 8060, http dx.doi.org/10.6028/
NIST.IR.8060 SWID tags are defined by ISO/IEC
197702:2015.
12 See, e.g., SwiftBOMSBOM Generator for PoC
and Demos, https democert.org/sbom/ last visited May 18, 2021.

VerDate Sep<11>2014

17:49 Jun 01, 2021

Jkt 253001

management, cybersecurity, and public policy. We seek comment on how these issues described below should be considered in defining SBOM elements today and in the future.
a. Software Identity: There is no single namespace to easily identify and name every software component. The challenge is not the lack of standards, but multiple standards and practices in different communities.
b. Software-as-a-Service and online services: While current, cloud-based software has the advantage of more modern tool chains, the use cases for SBOM may be different for software that is not running on customer premises or maintained by the customer.
c. Legacy and binary-only software:
Older software often has greater risks, especially if it is not maintained. In some cases, the source may not even be obtainable, with only the object code available for SBOM generation.
d. Integrity and authenticity: An SBOM consumer may be concerned about verifying the source of the SBOM
data and confirming that it was not tampered with. Some existing measures for integrity and authenticity of both software and metadata can be leveraged.
e. Threat model: While many anticipated use cases may rely on the SBOM as an authoritative reference when evaluating external information such as vulnerability reports, other use cases may rely on the SBOM as a foundation in detecting more sophisticated supply chain attacks.
These attacks could include compromising the integrity of not only the systems used to build the software component, but also the systems used to create the SBOM or even the SBOM
itself. How can SBOM position itself to support the detection of internal compromise? How can these more advanced data collection and management efforts best be integrated into the basic SBOM structure? What further costs and complexities would this impose?
f. High assurance use cases: Some SBOM use cases require additional data about aspects of the software development and build environment, including those aspects that are enumerated in Executive Order 14028.13
How can SBOM data be integrated with this additional data in a modular fashion?
g. Delivery. As noted above, multiple mechanisms exist to aid in SBOM
discovery, as well as to enable access to SBOMs. Further mechanisms and standards may be needed, yet too many 13 Exec. Order No.14028 4eix, 86 FR
26633, 2663839 May 12, 2021.

PO 00000

Frm 00025

Fmt 4703

Sfmt 4703

options may impose higher costs on either SBOM producers or consumers.
h. Depth. As noted above, while ideal SBOMs have the complete graph of the assembled software, not every software producer will be able or ready to share the entire graph.
i. Vulnerabilities. Many of the use cases around SBOMs focus on known vulnerabilities. Some build on this by including vulnerability data in the SBOM itself. Others note that the existence and status of vulnerabilities can change over time, and there is no general guarantee or signal about whether the SBOM data is up-to-date relative to all relevant and applicable vulnerability data sources.
j. Risk Management. Not all vulnerabilities in software code put operators or users at real risk from software built using those vulnerable components, as the risk could be mitigated elsewhere or deemed to be negligible. One approach to managing this might be to communicate that software is not affected by a specific vulnerability through a Vulnerability Exploitability eXchange or VEX,14
but other solutions may exist.
4. Flexibility of implementation and potential requirements. If there are legitimate reasons why the above elements might be difficult to adopt or use for certain technologies, industries, or communities, how might the goals and use cases described above be fulfilled through alternate means? What accommodations and alternate approaches can deliver benefits while allowing for flexibility?
Instructions for Commenters: NTIA
invites comment on the full range of issues that may be presented in this Notice, including issues that are not specifically raised in the above questions. Commenters are encouraged to address any or all of the above questions. Comments that contain references to studies, research, and other empirical data that are not widely available should include copies of the referenced materials with the submitted comments. Comments submitted by email should be machine-readable and should not be copy-protected.
Responders should include the name of the person or organization filing the comment, which will facilitate agency follow up for clarifications as necessary, as well as a page number on each page of their submissions. All comments received are a part of the public record and will be posted on regulations.gov 14 David Braue, Software Bill of Materials To Become Standard?, Info. Age Oct. 22, 2020, 11:34
a.m., https ia.acs.org.au/article/2020/softwarebill-of-materials-to-become-standard.html.

E:FRFM02JNN1.SGM

02JNN1