NTIA Examines Software Component Transparency, Previews SBoM

On July 19, 2018, the U.S. Department of Commerce’s National Telecommunications and Information Administration (NTIA) convened a multistakeholder process examining “Software Component Transparency.” This effort has long been discussed by NTIA, and among other things, reflects the Executive Branch agency’s early moves to implement the actions identified by the Report to the President on Enhancing Resilience Against Botnets. 

The NTIA, which serves as the principal advisor to the President on telecommunications and information policy, has facilitated consensus-based stakeholder-driven processes on several hot technology issues: cybersecurity, the Internet of Things, and the health of the digital ecosystem.

Background

As Wiley Rein previously discussed, this initiative will examine whether and how increased disclosures and transparency about software components can help with lifecycle management of IoT devices and security more broadly.  In particular, a software “bill of materials” (SBoM) is being considered as a tool in advancing software component transparency.

What is a Software Bill of Materials?

A software bill of materials (SBoM), which is a centralized comprehensive list of components contained within a product, is seen by some as helpful for both software manufacturers and enterprise customers to understand vulnerability risks.  Some consider a bill of materials to be a critical tool for supply chain management. Within traditional manufacturing, the bill of materials serves as a catalogue for each part used to create a product and is used in decision making at the design, engineering, manufacturing, supply chain, support and maintenance phases of a product.  The utility of a bill of materials in the software ecosystem is less obvious, but NTIA will explore this and related issues.

Arguments in Favor of a SBoM

An SBoM may be useful in the software development context where the use of third-party open source and commercial components, libraries, and modules is the standard. Proponents argue that in the event of a potential or eventual vulnerability, an SBoM helps determine: (1) whether a product is affected, (2) where the affected products are located, and (3) the appropriate incidence response. The NTIA has noted that “the notion of transparency around component software and connected devices is not new,” citing a host of applications related to security development, licensing and asset management.

In April of this year, NTIA Cybersecurity Director, Dr. Allan Friedman, hosted a discussion at the RSA Conference 2018, offering insights on tracking third party components in software and IoT with a software bill of materials.  According to Dr. Friedman, a software bill of materials can:

• Improve and communicate secure development practices,
• Help enterprise customers protect themselves, and
• Foster better markets for secure products.

Furthermore, from the vendor perspective, an SBoM can (1) enable the tracking of inputs and (2) aid in auditing for quality, risk management and compliance.  From the enterprise perspective, an SBoM could help customers to (1) compare solutions across the marketplace to make security decisions at the acquisition stage; (2) develop a threat assessment and mitigation strategy for potential risks; and (3) develop a lifecycle management program that addresses obsolete or unsupported components.

An SBoM May Not be the Right Tool and Raises Complexities  

Given the diversity of software inputs to modern technology, the global supply chains that create and purchase software-dependent products and services, and the varied users (large and small enterprises, federal purchasers, consumers) across an array of industries and settings, scoping this effort will be critical.  In past NTIA efforts, there have been difficulties in determining whether to take a broad approach that is generally applicable or identify particular examples or use cases that can be more actionable.  This challenge bore out yesterday afternoon as stakeholders grappled a variety of paths forward, ultimately deciding that more discussion was necessary.  NTIA is always clear that stakeholders determine the scope and goals, so participation will be key to this effort.  It is likewise unclear what the end product will actually look like. 

NTIA should heed existing software management approaches, avoid duplication, and solicit meaningful input on whether a gap exists that needs to be filled. There are existing tools in the marketplace that can support the standardized adoption of SBoMs.  Friedman highlights, among others, the National Institute of Standards and Technology (NIST) standards for software identification (SWID) tags, and Managing Security Risks Inherent in the Use of Third-Party Components, a private-industry resource on implementing an SBoM.

Beyond the technical aspects, advancing an SBoM as a solution will require greater focus on awareness, adoption, incentives, and understanding further barriers and concerns.  The standardized adoption of SBoMs may be a controversial idea because of the implications for intellectual property, software liability, and insurance. 

Nevertheless, the medical IoT space appears to be taking the lead on cybersecurity standards. In an effort to keep pace with emerging threats and vulnerabilities, the FDA recently announced plans to require firms to develop an SBoM that must be provided to the FDA and made available to medical device customers and users.

Wiley Rein looks forward to continuing to engage in the software component transparency initiative and is happy to answer any questions about the process and the wisdom of particular entities engaging with NTIA.

Tawanna Lee, a Law Clerk at Wiley Rein LLP, contributed to this alert.