The Software Bill of Materials (SBOM) has become a central part of the White House National Cyber Security Strategy to help protect the software supply chain supporting government and critical infrastructure systems. Standards for expressing and consuming SBOM data are maturing, and the CISA (Cybersecurity and Infrastructure Security Agency) has also published a thorough list of the types of SBOMs required to include the different development stages of the product lifecycle.
SBOMs act as a list of software ingredients. As such, they should include detailed safety information (source, version, history data, vulnerabilities, etc.) about every code element and object that goes into a software product. Experts predict that these ingredients will grow in 2024, particularly when it comes to AI-enabled safety-critical systems. Experts also predict how changes in open-source licensing will impact SBOM maintenance and usage. And, given these complexities, some experts feel that SBOMs are losing traction as government agencies struggle to find software product vendors that meet requirements in this evolving landscape.
Open-Source Licensing
Open-source code is at the core of the vast majority of safety-critical software systems. And,
Alan Shimel, CEO of Techstrong Group and DevOps.com, predicts that the golden age of free open source is coming to an end. For example, he points to HashiCorp, known for its popular Terraform infrastructure as a code platform, which announced in August that it is adopting a business source license that will restrict how organizations can modify and reuse the code in all future releases. A month earlier, Red Hat announced changes in Red Hat Linux licensing and support that will render republishing code that was acquired through its customer portal in violation of new licensing agreements.
“So now, with some of the most popular open-source platforms, you only get the source code if you are a paying customer,” Shimel explains. “We are also seeing some of Linux foundations laying people off because a lot of the companies pledging support for open source are pulling back because of macro-economic times. Open source won’t go away, but companies are re-evaluating their open-source business models.”
Shimel feels this trend will grow, so he advises developers to check their open-source licensing agreements on existing versions and future versions they intend to use. “This is where SBOMs will help developers because changes in these licensing agreements are truly dynamic,” he notes. Developers will need SBOMs to track all their components, versions, and vulnerabilities to keep current on changes in open-source licensing, which must scale to include all interdependencies between components and third-party apps the product interacts with. He adds, “I may have used this particular component that makes an API call to something else, which makes a call to something else, and developers will need to know if any components along that third-party dependency chain have changed on a licensing level.”
He also points to new maintenance headaches that should support older open-source versions going away. If that support disappears, product companies may have to tear components out and start over, or convert to the paid-for version, which could result in much higher development costs than in previous years, he adds.
System-Wide Bills of Materials
As more AI (artificial intelligence) and machine learning (ML) elements are implemented in vehicles and other safety-critical systems, SBOMs will also need to integrate with different types of Bills of Materials (BOMs) where SBOMs are only a part of the safety data manufacturers and regulators require, says Kate Stewart, VP of embedded systems at the Linux Foundation.
“We need to extend the SBOM into a ‘System Bill of Materials’ that joins all the ingredients—hardware, software, AI, and ML training data and services—to adequately describe what’s happening in systems with critical safety profiles, including automotive, aerospace, industrial, and more,” she explains.
During a December 2023 keynote at the Open Source Summit in Japan, she used the auto industry as her example, citing how, despite their training, half of self-driving cars on the road have been recalled for not recognizing school busses, emergency vehicles, or stop signs and other safety-related issues. She also cited a Washington Post article that reported that, since 2019, two-thirds of 736 smart vehicle crashes involved Tesla autopilot.
She then pointed out that there are more ingredients in our vehicles than just software and hardware. They also include AI training data, and communications to remote services, for example. To date, combining this data has been a mostly manual effort, but the maturation of standards like SPDX are also encompassing more types of BOM data. From a Linux perspective, she pointed to several working groups including Elisa, Zepher RTOS, Xen for Hypervisor, and yocto) to expand BOM data to include create/tool-chain data, AI training data, and testing data, for example.
SBOM Hype Cycle
How the data from all these BOMs will come together, even with these working groups and standards, will take time and effort. As such, SBOMs will continue to struggle with scalability and relevancy issues that will slow SBOM adoption, predicts Chris Hughes, president of government security services firm, Aquia, and cyber innovation fellow at the CISA (Cybersecurity and Infrastructure Security Agency), where he focuses on software supply chain security.
“The industry continues to talk a lot about SBOMs, but no one is using them at scale or having comprehensive SBOMs aligned with guidance such as the NTIA minimum elements for an SBOM. The industry will continue to drown in vulnerabilities, with backlogs in the hundreds of thousands to millions as a result of vulnerable software. Some of this is the unintended result of shifting security left with testing and scanning, which produces findings that may or may not need to be acted upon,” he notes.
He adds that less than six percent of CVE’s are exploited, and predicts that SBOMs will include exploitability scores by aligning with resources like the CISA’s Known Exploited Vulnerabilities Catalog (KEV) and the Exploit Prediction Scoring System (EPSS). Focusing on exploitability, he adds, should provide context and reduce the noise of too many vulnerabilities, helping product developers and product buyers focus only on those vulnerabilities that matter.
That said, much work has been done to automate SBOM generation, while intermediaries have sprung up to manage and keep them current. The more mature intermediaries are already helping users of the SBOMs prioritize vulnerability remediation based on KEV and other vulnerability scoring exchanges. For example, see our post demonstrating such capabilities here.
