Are software bills of materials ready for prime time?

Software companies are facing a similar regulatory issue that confronted the food industry in the 1960s – whether and how to disclose the ingredients that make up their products.

In response to pressure from consumer advocates, the U.S. Department of Agriculture required all food products to include an ingredients list by 1966 but it took decades and even a Supreme Court decision before regulators arrived at the format for the label posted on virtually every food product in America today. 

Earlier this month, the White House recommended federal agencies collect similar lists for software and implement full inventory assessments as part of an effort to ensure the government is purchasing secure software from trusted vendors. Those lists, known as Software Bills of Material (SBOMs), can help organizations ensure they are protected from known risks like the Log4Shell software flaw through increased visibility into their own networks. 

"SBOMs are like the basic 'ingredients list' that goes into your digital product," said Jon Geater, co-founder of the Software-as-a-Service (SaaS) platform RKVST. "So just like some people really need to know if a candy bar contains wheat or nuts, a digital consumer needs to know what is going into their estate."

Geater describes SBOMs as the first step in enterprises being able to properly manage their own risks: "If they wake up to a big news story like Log4Shell, they can now take a look at everything they have and instantly see where Log4j is in their infrastructure, without having to wait for all their vendors to separately and individually contact them."

President Joe Biden signed an executive order on improving the nation's cybersecurity last year which defined an SBOM as a "formal record containing the details and supply chain relationships of various components used in building software." 

The National Institute of Standards and Technology, which has published a set of supply chain cybersecurity best practices and a supply chain security framework, also recommends agencies require SBOMs from software vendors in all acquisitions. 

Through automation, continuous monitoring and other technology, organizations can also use SBOMs to identify and mitigate new threats across their systems emerging after the procurement process through software updates and vulnerabilities. 

"What we just saw from Log4j is that there is a need where we can improve the security for open source software," Phil Stupak, director of federal cybersecurity for the Office of the National Cyber Director, said at a recent GovCIO Media & Research about implementing SBOMs across agencies, adding: "We have an obligation to do that."

But some experts think more time is needed before the administration begins requiring agencies to adopt SBOMs, and that consumers and government customers are not yet aware how to fully leverage their various supply chain security benefits. 

Technology trade groups warned in a September letter to the chairs and ranking members of multiple congressional committees that "SBOMs will not achieve the desired utility for agencies at this point because of a lack of standardization" and that further guidance was necessary "on the structure and construction of an SBOM and standardization of the processes for SBOM dissemination, ingestion, and use."

The letter pushed back on language in the House-passed 2023 defense policy bill that would require software vendors to attest to the government that their products are free of known defects and to include a bill of materials describing their code. 

Ross Nodurft, former head of the Office of Management and Budget's cyber team and executive director of the Alliance for Digital Innovation, which signed onto the September 14 letter, told FCW that "focusing on SBOMs risks missing the forest for the trees."

"SBOMs can be a portion of any broader software supply chain risk management approach," he said.

Henry Young, director of policy for the BSA Software Alliance, also acknowledged that SBOMs can help an organization "understand the full composition of its software for successful incident response and recovery," though he added that the mandatory government-wide implementation of such inventory lists may not yet be ready for codification. 

"We know SBOMs deliver important information, but if the recipient of that data isn't ready to absorb and act on it, the information is simply not valuable," Young said. "Right now, vendors can put an SBOM together, but without industry standardization, the process for turning an SBOM into the action necessary to make concrete cybersecurity improvements isn't yet ready to be done at scale."

Despite concerns, lawmakers have moved forward with implementing SBOM requirements into recent legislation: A House-passed defense policy bill earlier this month includes a provision requiring outside software vendors attest to the secure development of their offerings. 

Meanwhile, the National Telecommunications and Information Administration (NTIA) has published various resources for organizations to help develop SBOMs from the ground up, including technical resources, introductory guides, surveys of existing standards and more. NIST has also published its own resources on SBOMs, including an illustrative example of how SBOMs can be assembled across the software development life cycle. 

With the current array of guidelines, standards and best practices published by the agencies tasked with developing such directives for the federal government, other experts say that now is the time for codification. 

"Long story short, there's more than enough guidance for agencies to properly begin producing – and requiring – SBOMs," said JC Herz, co-chair of the NTIA's Software Transparency Standards and Formats working group and cofounder of the software supply chain intelligence platform Ion Channel. "The uncomfortable unanswered question is: What are they going to do with the findings when it becomes obvious that vendors and contractors are not maintaining their products and deliverables?"

"Some very grown-up conversations will need to happen," Herz said.

Geater described SBOM files as "very well standardized today" and noted that trustworthy tooling is available to help build verifiable software supply chains "with high integrity attestations."

For now, federal civilian agencies are not yet required to adopt SBOMs into their acquisition processes, though that time appears to be soon approaching. The most recent guidance published by the Office of Management and Budget offers advice to organizations struggling to produce full SBOMs: Start off small, with letters of attestation from software providers confirming the secure development and shipment of their products. 

"These letters are not standardized, and probably never will be, but that doesn't matter," Geater noted. "It's the attestation that is important, ensuring that evidence you rely on today will remain independently verifiable and can't be modified, shredded, or deleted." 

As the White House and Congress move towards fully implementing SBOMs, industry groups have vowed to provide input and collaborate to ensure federal agencies maximize the attainable benefits from the process.