NTIA makes significant changes for development of a model for SBOMs, including software components
The Framing working group of the National Telecommunications and Information Administration (NTIA) has published a document that lists significant changes for the development of a model for a Software Bill of Materials (SBOM) that delivers a machine-readable inventory of software components. It also looks into how SBOMs can be shared, and how they can be used to help foster better security decisions and practices.
To make the SBOM useful, the initiative will also need to outline the applicable use cases to ensure that the output is useful for all stakeholders. All industries utilizing or producing software are part of the initiative, including automotive, financial, healthcare, operational technology (OT), and traditional IT environments.
An SBOM is primarily a formal, machine-readable inventory of software components and dependencies, information about those components, and their hierarchical relationships, the report identified. These inventories should be comprehensive – or should explicitly state where they could not be. SBOMs may include open source or proprietary software and can be widely available or access-restricted. Structured data formats and exchange protocols are also key attributes of a functional SBOM because they enable machine readability and automation, it added.
The document adds a timestamp to baseline attributes, provides clarified requirements aspects of baseline attributes, and adds CycloneDX as an additional format. It also removes some existing formats and has been renumbered accordingly. The NTIA record has also updated language in baseline attributes and terminology, updated and harmonized language across working groups, with modernized figures and tables, and has made various editorial improvements and clarifications.
Titled, ‘Framing Software Component Transparency: Establishing a Common Software Bill of Materials (SBOM) Second Edition,’ the document reveals that the NTIA multistakeholder process has created a model for software component information that can be universally and transparently shared across industry sectors. The model defines and describes an SBOM, addresses relationships between components, creation and sharing of SBOMs, roles of participants, and SBOM integration with supply chains.
The NTIA document discloses that the lack of systemic visibility into the composition and functionality of modern software systems is a result of increasingly complex and dynamic supply chains that substantially contribute to cybersecurity risk. It also increases costs of development, procurement, and maintenance, apart from rising risk and cost impact for individuals and organizations, and collective goods such as public safety and national security.
The NTIA Software Component Transparency multistakeholder process reviewed existing software identification formats, considered feedback from the healthcare ‘Proof of Concept’ exercises, and thoroughly debated and questioned which elements would be necessary to create a scalable and functional SBOM system, the document said. Many of the answers depend on the desired use cases that can be built on top of sufficient quantity and quality of baseline SBOM data. Without a way to systematically and consistently define and identify software components and their relationships, none of the desired use cases will function at scale, it added.
To scale the model globally, it is necessary to address the difficult problem of universally identifying and defining certain aspects of software components. So a subsidiary goal was to select a core, baseline set of attributes necessary to identify components with sufficient relative uniqueness, the NTIA said. Another goal was to capture SBOM applications and consider what additional, optional attributes and external elements might be needed beyond the baseline set.
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 the software supply chain, and propose various solutions.
The earlier 2019 document came after a July 2018 meeting of stakeholders from across multiple sectors to begin a discussion about software transparency and the proposal being considered for a common structure for describing the software components in a product containing software. The output of this meeting was to create several task groups, which then led to documents produced by each of these groups.
The latest Framing working group document comes in response to U.S. President Joe Biden’s Executive Order (14028) on ‘Improving the Nation’s Cybersecurity’ in May. Following the cybersecurity incident by ransomware attackers on the Colonial Pipeline, the presidential action identified, among other things, SBOM as a priority for the administration and other stakeholders to drive software assurance and supply chain risk management. The Department of Commerce subsequently in coordination with the NTIA was to publish the minimum elements for an SBOM.
In July, the NTIA published a report on the minimum elements for an SBOM, which was intended to serve as a foundation for continued collaboration and public-private partnerships to refine and operationalize SBOM work.
The primary goal of the Framing working group was to create a model for software component information that can be universally and transparently shared across industry sectors that would help achieve greater supply chain transparency.
Increased supply chain transparency can reduce cybersecurity risks and overall costs by improving the ability to identify vulnerable software components that contribute to cybersecurity incidents, and reducing unplanned and unproductive work due to convoluted supply chains, according to the document. It also allows vendors that support transparency to help differentiate themselves in the market, reduce duplication of effort by standardizing formats across multiple sectors and facilitate the identification of suspicious or counterfeit software components.
Last week, the U.S. House of Representatives passed the DHS Software Supply Chain Risk Management Act of 2021 with a 412-2 vote. The legislation, introduced by Rep. Ritchie Torres, a Democrat from New York, requires the Department of Homeland Security (DHS) to develop guidelines for identifying materials used in software development. Specifically, the legislation directs DHS to modernize its information and communication technology or services acquisitions process by requiring the Under Secretary for Management to issue department-wide guidance to require DHS contractors to submit SBOMs that identify the origins of each component of the software furnished to DHS.
Ultimately, the benefit of SBOMs is to provide actionable information to purchasers so that they may make informed decisions about software and help to improve the security of applications, Fortress identified in a recent white paper. “While many standards and guidelines require varying levels of software security, an effectively prepared and analyzed SBOM can be invaluable in meeting tomorrow’s critical infrastructure application cybersecurity challenges,” it added.
Related
