There are a lot of things involved in SBOMs, with many working groups behind them—all of which will impact commercial software products from web and cloud applications, to embedded code in medical devices, cars, and printer drivers.
By Deb Radcliff,
In June, the Cybersecurity and Infrastructure Agency convened a full-day SBOM-A-RAMA to update and share efforts in securing the software supply chain and protecting government agencies and critical infrastructure. As if to make the point hit home, multiple federal and state agencies were at the time experiencing sensitive data breaches through a popular commercial software program called MOVEit, which was being actively exploited by Russian cybercriminals. The FBI called this a “very serious breach” and released two CVE’s on it, adding to a growing database of massively-exploitable vulnerabilities in commercial software that government agencies rely on.
Based on the many working groups who presented at the SBOM-A-RAMA, it was obvious that the U.S. Government is serious about holding software product vendors of all types accountable for reducing these risks by any means necessary. Referring to the buying power of the U.S. Government, Allan Friedman, senior advisor and strategist at the CISA (who is often referred to as the father of the SBOM), put it this way: “We are using our bully pulpit across sectors,” to get commercial vendors to create more secure software and get on board with Software Bills of Materials “because there is no secure future without SBOMs.”
Multiple working groups are putting their resources behind various elements of the SBOM efforts based on the wide range of speakers at SBOM-A-RAMA. Some groups were based on application types, including cloud, OT, auto, financial, and healthcare apps. Others were regional, with speakers representing the U.S., UK, Brussels, and Japan. Following a crawl, walk, run roadmap, other working groups focused on developing, consuming, sharing, and standards for SBOM data sharing. Every speaker representing these working groups spent a moment recruiting others to join their cause.
Pro Tip: Get involved! Follow this Google Docs link to SBOM working groups and documentation.
U.S. and EU Legislation
Benjamin Bogel, policy officer on cybersecurity at the European Commission, spoke virtually from Brussels, explaining new legislation in the EU that is calling for software manufacturers to focus on secure coding and how SBOMs fall under the EU Cyber Resilience Act (passed in September 2022) to include technical documentation to prove conformity. This, he added, applies to traditional software, OT, and hardware CPUs.
Following Bogel, Charlie Hart, SVP of engineering at Hitachi and chair of the automotive working group under the Automotive ISAC, explained that there are at least 100 software vendors involved in car production today, and discussed how threats aimed at exploiting these applications are on the rise. “In March of 2019, the automotive ISAC started seriously thinking about SBOMS,” he said of the industry’s SBOM efforts. “We are currently in phase three to do tabletop and live fire exercises against these applications to get participants ready to actively produce SBOMs.”
Pro Tip: Check out the OECD (international Organisation for Economic Co-operation and Development) policy discussion on cloud, IOT, and smart products containing code.
Pain Points a Plenty
The difficulties in extracting and sharing SBOM data were readily apparent based on several presentations. Art Manion, formerly technical manager of the CERT Division at the Software Engineering Institute, explained the status of VEX (the Vulnerability Exploitability eXchange) from his seat as co-chair on the VEX working group. He showed a graph listing the myriad components in a commercial application. Then he drilled down on the vulnerabilities within the components, for example, an old compression library in one of the components. “But how do they [the users] know if that vulnerability affects a user’s newer version of the library?” he asked. VEX, which should ultimately help answer such questions, is in the intermediate stage, he added, but there is more work to do.
“It’s hard, but SBOM sharing is being done today, although there are gopher holes everywhere. For example, sometimes, what’s in the SBOM doesn’t match the hash due to configuration issues,” added Chris Blask, co-chair of the SBOM sharing group. Open-source providers, commercial software vendors, integrators, regulators, private sector to public sector exchange and delivery must all be represented in SBOM sharing, he said and should speak in the language of procurement, application managers, along with vulnerability and configuration managers who are consuming these reports.
Embedded Software Systems in OT
Kate Stewart, VP at Dependable Embedded Systems at the Linux Foundation, and Melissa Rhodes, SBOM program manager at Medtronic, talked about tooling and implementation—specifically how to make embedded systems more transparent with SBOMs. Stewart explained that one of the biggest pain points among vendors surveyed was understanding the format and syntax for filling out minimum fields in SBOM disclosure reports. She then described a collaboration with OpenSSF for SBOM everywhere to help standardize SBOM fields.
“Someone doing a source scan for their legal team will be after different things than the vendor building the SBOM. Let’s see if we can get a language to talk the same thing,” Stewart noted. Top priorities include structural correctness and content accuracy, along with usefulness of information, she continued. To get to this degree of visibility into embedded systems, she called out SBOMs for design, source, build, analyzed, and deployed code.
Pro Tip: Learn how GrammaTech’s CodeSentry generates SBOMs for deployed code.
Stewart also brought up SBOMs for artificial intelligence in the future, while Blask mentioned how the software industry should be considering SBOMs for quantum computing and encryption. Friedman added that the government is working out how it will swap encryption in systems and pointed to SDX and CycloneDX standards to populate and build databases for encryption SBOMs.
Self-Attestation Update
Finally, the issue of where the OMB (U.S. Office of Management and Budget) stands on
self-attestation for software makers came up. OMB memorandum 23-16 reinforces requirements to M-22-18, enhancing the software supply chain through secure development practices. As the self-attestation forms are not yet finalized, government agencies have been given an extension of three months after the self-attestation forms are finalized before they are required to use them with their software producers.
“Not having a firm date gave us room to be sure we’re being strategic and thoughtful in the questions we ask of our [software] vendors. I hope both sides [producers and buyers] can have a little bit of ease in that,” said Shon Lyublanovitz, cyber supply chain risk management lead at the CISA. “We are also making sure that we are advocating [for buyers and sellers].”
Early version self-attestation forms (not the final forms) can be found here. Self-attestation may be more useful for software vendors that provide new updates on a regular basis (and thus can’t keep issuing new SBOMs for each update), as well as for those who cannot initially provide an SBOM. But the self-attestation forms must still prove that the software is in compliance with NIST SP 800-218: Secure Software Development Framework (SSDF), and ultimately all commercial software providers will still be required to produce an SBOM for their products.
Pro Tip: Read the GrammaTalk blog on the difference between self-attestation and SBOMs and why both are needed.
