The Commerce Department-led working group on software transparency would be an appropriate venue for discussions of a Pentagon pilot program around holding the tech industry responsible for managing cyber risks related to their products, according to the group’s coordinator.
The National Telecommunications and Information Administration multistakeholder group held a webinar Thursday to discuss drafts of work products completed so far and next steps toward standardizing and fostering greater use of a “software bill of materials,” which is often described as an ingredients list of the commonly long and complex chain of components used by developers of what has been noted is currently the most successful vector for cyber attacks.
“I think that's an excellent idea worth exploring,” said Allan Friedman, the director of cybersecurity programs at NTIA who facilitates the multistakeholder group, referring to the proposed DoD pilot program.
“One of the foundational missions of this initiative is to sort of start with that transparency layer,” he said. “I think having the input of some of the working groups here to say well what would that pilot look like, is something that we can facilitate.”
Friedman was responding to comments from Robert Metzger, head of the DC office for law firm Rogers Joseph and O'Donnell and an author of “Deliver Uncompromised: A Strategy for Supply Chain Security and Resilience in Response to the Changing Character of War.”
“Thinking about it from the Department of Defense standpoint,” Metzger said, “would it make the most sense for DoD to be thinking that it should call for SBOMs as part of bundled responsibility or activity such that software sources would be at once required to build an SBOM and to monitor the software for vulnerabilities as they emerge and to take responsibility themselves to correct it?”
Metzger asked, “Would it be worthwhile to pilot initiatives where DoD might call upon prospective suppliers, or current suppliers, of software to assume this responsibility for all three components?”
Other participants seemed to support the direction of the probe from Metzger, who noted it wouldn’t be timely for the end user to have the responsibility of monitoring for and fixing any vulnerabilities in the software inventory, and suggested those responsibilities be more appropriately assigned to the software makers by contract.
“In the oil industry,” one participant said, speaking to their experience, “the tradition is that you buy whatever it is from a supplier and you hold that supplier accountable for anything that goes on in that component, whether it's an open exhaust system...you go back to your supplier and point your finger at them, and then they have to tell you what to do.”
The Defense Department is seen as being on the more mature end of the spectrum when it comes to using SBOMs for “high assurance.”
One of the four multistakeholder working groups -- focused on practices currently in place that resemble the production and use of an SBOM – put end users in the healthcare industry, in association with their use of medical devices, on the other end of that spectrum. They quoted sources at Health Delivery Organizations they interviewed as saying “our vendors are clueless!” “SBOM is QA’s problem!” and “Vetting is too much work!”
The roles and responsibilities in that space especially lacked clarity, the working group’s leaders said.
Which is why the NTIA group was buoyed by the initial report of another working group – a collection of Health Care Delivery organizations and Medical Device Manufacturers -- who set out on a Proof of Concept that could be used to evangelize the SBOM.
The group said that while there were still challenges to work through in terms of tools needed to automate the process of producing the SBOM, they were successful in finding and mitigating vulnerabilities they identified thanks to the SBOM.
Friedman stressed the importance of automating the process, which comes back to the timeliness needed to respond to real-world scenarios.
Participants expressed enthusiasm about signing up for a “2.0” project to develop the necessary tools. Entities like Splunk and Github were mentioned as potentially being key players on that front.
The group expects to have a polished work product out in August and to discuss next steps for promotion and adoption. The next in-person meeting is scheduled for Sep. 5. – Mariam Baksh (mbaksh@firstname.lastname@example.org)