A Commerce Department-led initiative to develop a common software component vulnerability framework is still a work in progress, says BSA-The Software Alliance leader Tommy Ross, and more development is needed to mature the project before it can widely adopted by agencies and industry.
The National Telecommunications and Information Administration is in the second year of a multistakeholder initiative to build a Software Bill of Materials that can be used across the entire software ecosystem. Stakeholders are meeting today to discuss the status of working group initiatives and circulate draft guidance documents.
The most valuable components of the SBOM will be the “naming conventions” which are “the ways vendors or developers will have to communicate to users of components downstream [how] they have potentially mitigated some of the risks that may be associated with components because of SBOM,” Ross said. Developing the nomenclature is ongoing.
Tommy Ross, Senior Director of Policy, BSA | The Software Alliance
Ross spoke with Inside Cybersecurity on the value of the NTIA effort and what BSA-The Software Alliance would like to see emerge from the multistakeholder process. Ross is the association’s senior director of policy.
BSA-The Software Alliance wants to build “a clear understanding among users of what the SBOM is and what it is not,” and to figure out “what aspects of software security that SBOM is useful in addressing and the remaining areas of security that SBOM doesn't cover,” Ross said.
“SBOM isn't going to be a stand-in for software security as a whole,” he said. “It is one potential tool that may be useful in addressing third party components, hopefully their integration in a security manner and their upkeep and maintenance. But it is no substitute for a broader secure development lifecycle and in fact needs to live within a broader secure lifecycle in order to be effective.”
At the last stakeholder meeting in April, participants heard from Jessica Wilkerson, cyber policy advisor at the Food and Drug Administration, who revealed that her agency is planning to incorporate the initial documents produced by the working groups into guidance for the medical device industry. The FDA has developed draft guidance on the “Content of Premarket Submissions for Management of Cybersecurity in Medical Devices,” which was released in October 2018.
Ross said there are clear applications on how the SBOM initiative could inform the FDA’s work because of proofs of concept developed by one of the SBOM working groups focusing on medical devices, with device manufacturers and five hospitals participating in the project.
“As government agencies are looking at SBOM, one of the things that we think is really important is that SBOM be situated not only in an understanding of both how the tool functions within a broader scope of software security and secure development, but also there should be a broader understanding at agencies of the policy foundations that are needed to support and enable the SBOM to be a useful tool,” Ross said. “Those are conversations that have been a little outside the scope of the NTIA working group so it's going to be up to us as a community to pursue those conversations.”
To enable agency adoption, Ross said individual agencies will “need to have policies in place around vulnerability management,” and “contract policies in place that lay out responsibilities for addressing vulnerabilities in software products that are developed or maintained by entities, businesses or others.”
Ross said these conversations focused on policies need to happen and industry should be engaged in the initiative, but SBOM is currently “not ripe for adoption by government agencies.”
NTIA has the capability to drive “a consensus in different communities” on what should be included in a common model on “software development methodologies and approaches to a secure lifecycle and different coding languages,” Ross said. He praised the ongoing efforts of SBOM as a “really good approach” to sort out some of these issues.
Ross said, “The NTIA process provides a standardized format for developers to provide that information when asked and for customers who are asking for that information to insist upon. It normalizes those conversations potentially. That’s the benefit. If the demand is already there it provides a more useful way for that demand to be met.”
Working groups will discuss draft materials they have developed to spread awareness. The framing group will be presenting a “Software Identity Discussion and Guidance” white paper and a document on “Sharing and Exchanging SBOMs.”
The formats and tooling group will unveil the “SBOM Tool Classification Taxonomy,” and the adoption and awareness group will circulate a “SBOM Overview ‘two-pager’” explaining the initiative and an FAQ.
The SBOM work is intended to create a voluntary framework for organizations to follow, which Ross said is a benefit to industry.
Ross said, “SBOM is a potential tool to help organizations that are already wrestling with this problem and I think BSA and many others in industry would be concerned about premature mandates for the SBOM to be included with government software contracts and things like that.”
He said, “I don’t think it’s outside the realm of possibility that SBOM will reach a level of maturity when it can be a useful tool to government agencies or others, but it’s one step at a time. The first step is to try to figure out some of these thorny issues and see how the format works in practice. Pilots will help with that. As we see early adoption, we will get a flavor of how SBOM is used across sectors and that will be very helpful. Based on that data, the picture will continue to evolve, be refined and be improved.” -- Sara Friedman (sfriedman@iwpnews.com)