Notice2021-11592
Software Bill of Materials Elements and Considerations
Primary source
Metadata and text below are from the Federal Register, a public-domain U.S. government work. Always verify the official published version before relying on it for any legal matter.
Published
June 2, 2021
Issuing agencies
Commerce DepartmentNational Telecommunications and Information Administration
Abstract
The Executive Order on Improving the Nation's Cybersecurity directs the Department of Commerce, in coordination with the National Telecommunications and Information Administration (NTIA), to publish the minimum elements for a Software Bill of Materials (SBOM). Through this Notice, following from the Executive Order, NTIA is requesting comments on the minimum elements for an SBOM, and what other factors should be considered in the request, production, distribution, and consumption of SBOMs.
Full Text
<html>
<head>
<title>Federal Register, Volume 86 Issue 104 (Wednesday, June 2, 2021)</title>
</head>
<body><pre>
[Federal Register Volume 86, Number 104 (Wednesday, June 2, 2021)]
[Notices]
[Pages 29568-29571]
From the Federal Register Online via the Government Publishing Office [<a href="http://www.gpo.gov">www.gpo.gov</a>]
[FR Doc No: 2021-11592]
-----------------------------------------------------------------------
DEPARTMENT OF COMMERCE
National Telecommunications and Information Administration
[Docket No. 210527-0117]
RIN 0660-XC051
Software Bill of Materials Elements and Considerations
AGENCY: National Telecommunications and Information Administration,
U.S. Department of Commerce.
ACTION: Notice, request for public comment.
-----------------------------------------------------------------------
SUMMARY: The Executive Order on Improving the Nation's Cybersecurity
directs the Department of Commerce, in coordination with the National
Telecommunications and Information Administration (NTIA), to publish
the minimum elements for a Software Bill of Materials (SBOM). Through
this Notice, following from the Executive Order, NTIA is requesting
comments on the minimum elements for an SBOM, and what other factors
should be considered in the request, production, distribution, and
consumption of SBOMs.
DATES: Comments are due on or before June 17, 2021.
ADDRESSES: Written comments may be submitted on this document
identified by NTIA-2021-0001 through <a href="http://www.regulations.gov">www.regulations.gov</a> or by email to
<a href="/cdn-cgi/l/email-protection#366574797b696470757658425f5718515940"><span class="__cf_email__" data-cfemail="98cbdad7d5c7cadedbd8f6ecf1f9b6fff7ee">[email protected]</span></a>. Written comments also may be submitted by mail to
the National Telecommunications and Information Administration, U.S.
Department of Commerce, 1401 Constitution Avenue NW, Room 4725, Attn:
Evelyn L. Remaley, Acting NTIA Administrator, Washington, DC 20230. For
more detailed instructions about submitting comments, see the
``Instructions for Commenters'' section at the end of this Notice.
FOR FURTHER INFORMATION CONTACT: Allan Friedman, National
Telecommunications and Information Administration, U.S. Department of
Commerce, 1401 Constitution Avenue NW, Room 4725, Washington, DC 20230;
telephone: (202) 482-4281; email: <a href="/cdn-cgi/l/email-protection#9efff8ecf7fbfaf3fff0def0eaf7ffb0f9f1e8"><span class="__cf_email__" data-cfemail="046562766d616069656a446a706d652a636b72">[email protected]</span></a>. Please direct
media inquiries to NTIA's Office of Public Affairs: (202) 482-7002;
email: <a href="/cdn-cgi/l/email-protection#017173647272416f7568602f666e77"><span class="__cf_email__" data-cfemail="82f2f0e7f1f1c2ecf6ebe3ace5edf4">[email protected]</span></a>.
SUPPLEMENTARY INFORMATION:
Background
On May 12, 2021, the President issued Executive Order 14028,
``Improving the Nation's Cybersecurity.'' \1\ An initial step towards
the Executive Order's goal of ``enhancing software supply chain
security'' is transparency. As the Order itself notes, ``the trust we
place in our digital infrastructure should be proportional to how
trustworthy and transparent that infrastructure is, and to the
consequences we will incur if that trust is misplaced.'' An SBOM
advances transparency in the software supply chain, similar to a ``list
of ingredients.'' NTIA is directed to publish a list of ``minimum
elements for an SBOM.''
---------------------------------------------------------------------------
\1\ Exec. Order No. 14,028 of May 12, 2021, 86 FR 26,633 (May
17, 2021).
---------------------------------------------------------------------------
NTIA has played a leadership role in advocating for SBOM, convening
experts from across the software world and leading discussions around
the ideas of software supply chain transparency.\2\ The goal of this
Request for Comments is to seek input and feedback on NTIA's approach
to developing and publishing the minimum elements of an SBOM. NTIA is
committed to being open to further additions, corrections, deletions,
or other changes, particularly when suggestions are well supported with
[[Page 29569]]
documents, operational evidence, and support from broad-based
constituencies in the software ecosystem.
---------------------------------------------------------------------------
\2\ See David J. Redl, NTIA Launches Initiative to Improve
Software Component Transparency, Nat'l Telecomm. & Info. Admin.
(June 6, 2018), <a href="https://www.ntia.doc.gov/blog/2018/ntia-launches-initiative-improve-software-component-transparency">https://www.ntia.doc.gov/blog/2018/ntia-launches-initiative-improve-software-component-transparency</a>; Allan Friedman,
Dir., Cybersecurity, Nat'l Telecomm. & Info. Admin., Transparency in
the Software Supply Chain: Making SBOM a Reality, Address at Black
Hat USA 2019 Conference (Aug. 7, 2019).
---------------------------------------------------------------------------
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.
---------------------------------------------------------------------------
\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, 1-2 (2021), <a href="https://doi.org/10.1038/s41746-021-00403-w">https://doi.org/10.1038/s41746-021-00403-w</a>.
\5\ See Susan Miller, Protecting the Supply Chain with a
Software Bill of Materials, GCN (Feb. 22, 2021), <a href="https://gcn.com/articles/2021/02/22/sbom-supply-chain-security.aspx">https://gcn.com/articles/2021/02/22/sbom-supply-chain-security.aspx</a>.
---------------------------------------------------------------------------
What is an SBOM?
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.
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 third-party components that make up
software, certain data about each of those components should be
tracked. This ``baseline component information'' includes: \6\
---------------------------------------------------------------------------
\6\ See generally Framing Working Grp., Nat'l Telecomm. & Info.
Admin., Framing Software Component Transparency (2019), <a href="https://www.ntia.gov/files/ntia/publications/framingsbom_20191112.pdf">https://www.ntia.gov/files/ntia/publications/framingsbom_20191112.pdf</a>
(providing further information on baseline components).
<bullet> Supplier name
<bullet> Component name
<bullet> Version of the component
<bullet> Cryptograph hash of the component
<bullet> Any other unique identifier
<bullet> Dependency relationship
<bullet> 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, ``[c]omponent identification is fundamental to
SBOM and needs to scale globally across diverse software ecosystems,
sectors, and markets.'' \7\ The challenge is that different technical
communities and organizations have different approaches to determining
software identity.
---------------------------------------------------------------------------
\7\ Framing Working Group, Nat'l Telecomm. & Info. Admin.,
Software Identification Challenges and Guidance (2021), <a href="https://www.ntia.gov/files/ntia/publications/ntia_sbom_software_identity-2021mar30.pdf">https://www.ntia.gov/files/ntia/publications/ntia_sbom_software_identity-2021mar30.pdf</a>.
---------------------------------------------------------------------------
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:
<bullet> 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.
<bullet> 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.
<bullet> 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
[[Page 29570]]
services can have pointers to SBOM data stored online.
---------------------------------------------------------------------------
\8\ Framing Working Grp., Nat'l Telecomm. & Info. Admin.,
Sharing and Exchanging SBOMs (2021), <a href="https://www.ntia.gov/files/ntia/publications/ntia_sbom_sharing_exchanging_sboms-10feb2021.pdf">https://www.ntia.gov/files/ntia/publications/ntia_sbom_sharing_exchanging_sboms-10feb2021.pdf</a>.
---------------------------------------------------------------------------
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\
---------------------------------------------------------------------------
\9\ See also SPDX, <a href="https://spdx.dev/">https://spdx.dev/</a> (last visited May 18,
2021).
\10\ See also CycloneDX, <a href="https://cyclonedx.org/">https://cyclonedx.org/</a> (last visited
May 18, 2021).
\11\ See David Waltermire et al., Guidelines for the Creation of
Interoperable Software Identification (SWID) Tags (2016) (Nat'l
Inst. of Standards & Tech. Internal Rep. 8060), <a href="http://dx.doi.org/10.6028/NIST.IR.8060">http://dx.doi.org/10.6028/NIST.IR.8060</a> (SWID tags are defined by ISO/IEC 19770-
2:2015).
\12\ See, e.g., SwiftBOM--SBOM Generator for PoC and Demos,
<a href="https://democert.org/sbom/">https://democert.org/sbom/</a> (last visited May 18, 2021).
---------------------------------------------------------------------------
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.
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 NTIA's 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
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?
---------------------------------------------------------------------------
\13\ Exec. Order No.14028 Sec. 4(e)(i)-(x), 86 FR 26633, 26638-
39 (May 12, 2021).
---------------------------------------------------------------------------
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 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.
---------------------------------------------------------------------------
\14\ David Braue, Software `Bill of Materials' To Become
Standard?, Info. Age (Oct. 22, 2020, 11:34 a.m.), <a href="https://ia.acs.org.au/article/2020/software-bill-of-materials-to-become-standard.html">https://ia.acs.org.au/article/2020/software-bill-of-materials-to-become-standard.html</a>.
---------------------------------------------------------------------------
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 <a href="http://regulations.gov">regulations.gov</a>
[[Page 29571]]
and the NTIA website, <a href="https://www.ntia.gov/">https://www.ntia.gov/</a>, without change. All
personal identifying information (for example, name, address)
voluntarily submitted by the commenter may be publicly accessible. Do
not submit confidential business information or otherwise sensitive or
protected information.
Dated: May 27, 2021.
Kathy D. Smith,
Chief Counsel, National Telecommunications and Information
Administration.
[FR Doc. 2021-11592 Filed 6-1-21; 8:45 am]
BILLING CODE 3510-60-P
</pre><script data-cfasync="false" src="/cdn-cgi/scripts/5c5dd728/cloudflare-static/email-decode.min.js"></script></body>
</html>Indexed from Federal Register on June 2, 2021.
This is legal information, not legal advice. Laws vary by jurisdiction and change frequently. Always verify current law with official sources and consult a licensed attorney in your jurisdiction for advice on your specific situation.