The Software Bill of Materials 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 has also published a thorough list of the types of SBOMs required to include the different development stages of the product lifecycle.
They should include detailed safety information 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.
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 code is at the core of the vast majority of safety-critical software systems.
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.
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.
As more AI and machine learning elements are implemented in vehicles and other safety-critical systems, SBOMs will also need to integrate with different types of Bills of Materials 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.
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.
How the data from all these BOMs will come together, even with these working groups and standards, will take time and effort.
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, where he focuses on software supply chain security.
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 and the Exploit Prediction Scoring System.
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.
This Cyber News was published on securityboulevard.com. Publication date: Fri, 15 Dec 2023 16:13:04 +0000