Inside Cybersecurity

April 19, 2024

Daily News

Industry questions maturity of Software Bill of Materials concept to be used effectively across government

By Sara Friedman / June 21, 2021

Several trade associations are expressing concern over requirements in President Biden’s May cyber executive order around a Software Bill of Materials and whether the concept is mature enough to be a requirement in government contracts.

The EO tasks the National Telecommunications and Information Administration with determining the “minimum elements” of an SBOM and working with NIST to develop guidelines for “providing a purchaser a Software Bill of Materials (SBOM).” The SBOM could be provided by the contractor directly for each product or through making the information available by “publishing it on a public website.”

NTIA issued a request for comment earlier this month asking for industry input.

“Although not explicitly in scope of this RFC, we think it important to emphasize that further down the road, as NIST consults with stakeholders for the purpose of identifying practices that enhance supply chain security pursuant to sec. 4 of the EO (including to consider whether standards, procedures, or guidelines regarding SBOM are sufficiently mature), it should also take into account that SBOM is not yet widely practiced and therefore, it may be too soon to actually identify it as a best practice sufficient to potentially form the basis of a requirement,” the Information Technology Industry Council said in comments submitted last week.

ITI said, “The elements of an SBOM should reflect currently established best practices; we shouldn’t add requirements to an SBOM first and then develop consensus practices and standards to match those requirements later. We are not suggesting SBOM should not be explored further -- this RFC is a helpful first step to begin the process of identifying and driving consensus, as is the work that is being undertaken by NTIA more broadly.”

ITI in its comments discusses the risks of making an SBOM publicly available, who has the responsibility for generating an SBOM, potential overlap with NIST standards, and concerns over how an SBOM will provide “software users with actionable vulnerability information in certain contexts.”

“While it may be a legitimate aspirational goal to improve cybersecurity by developing new practices and standards for secure software development and coding, we suggest that such work must first be advanced (most appropriately, through processes run by NIST) prior to determining that such elements are ripe for inclusion in an SBOM,” ITI said. “A further complication is that vulnerability information is very context-specific. Without the ability to identity and reflect the appropriate context, it is challenging to act on certain types of information that may be provided in an SBOM. That being said, we also appreciate that NTIA recognizes this challenge and has proposed that one way to address it is to indicate that the software is ‘not affected’ by a specific vulnerability by tying it to a Vulnerability Exploitability Exchange (VEX).”

BSA-The Software Alliance cautions NTIA to resist creating SBOM guidelines that are “too prescriptive or not understood as a smaller part of a larger cybersecurity risk management program” because they “can offer misleading information or simply not be a useful security investment.” BSA said if an SBOM is “properly tailored and aligned with international standards” that it “can provide useful information to customers.”

“BSA recommends NTIA explicitly recognize that while an SBOM can improve cybersecurity it is appropriately understood as a smaller piece of a larger cybersecurity risk management program and that a vulnerability identified by an SBOM might not actually be exploitable,” the software association said in its comments to NTIA.

The Cybersecurity Coalition calls the SBOM definition in the EO “aspirational” and said there is “still a great deal of work required to define and document what SBOMs are and to make SBOMs prevalent within commercial software.”

The coalition said in its comments, “The U.S. Government should not be considering requiring vendors to produce something before real specifications are documented, as to what is required, how they work for specific use cases, and generally understood by government, those required to provide them, and those that would use them on the customer side.”

The Telecommunications Industry Association submitted comments to NTIA urging the agency to utilize work already completed by industry when crafting guidelines.

“The Telecommunications Industry Association (TIA) and its members believe utilizing SBOM will play a critical role in information and communication technology (ICT) security, and as an industry have been working for over a year and half on a process-based standard to help secure the ICT supply chain and address these concerns,” TIA said in its comments. “The standard is based on ISO 9001 and TL 9000, the only process-based standard focused on communications service. Supply Chain Security (SCS) 9001 will be released by the end of 2021. SCS 9001 not only addresses the security of the ICT supply chain but also covers security of the software development process.”

NTIA also received comments from Ion Channel, a company focused on software supply chain assurance. Ion Channel chief operating officer JC Herz is the co-chair of the formats and tooling working group for NTIA’s software transparency initiative.

“By way of feedback to the NTIA call for feedback on minimum fields, it’s important to understand whether an SBOM is produced pre-build, at-build-time or post-build,” Ion Channel said. “For SBOMs produced at-build-time or post-build, hashes are desirable - whether they should be required as minimum viable or not, at present, is a thorny business process and technical maturity question. A large number of software suppliers cannot meet that mark at present, and a higher bar may thwart adoption in the near-term, although the bar should definitely be raised as adoption increases.”

Ion Channel continued: “The pragmatic thing to do would be to drive adoption as broadly as possible, and then raise the bar. Any SBOM is miles better than no SBOM, for the simple reason that having to produce an SBOM drives unprecedented introspection by suppliers with minimal levels of maturity. The simple act of assembling or curating and inventory puts suppliers on another level of maturity - and it will be highly resisted if it’s not seen as an attainable goal.” -- Sara Friedman (sfriedman@iwpnews.com)