A software bill of materials (SBOM) would document third-party software components, including open source and commercial code.
Of the many solutions proposed to secure the software supply chain in the aftermath of the SolarWinds hack, among the most discussed is a software bill of materials (SBOM).
As we’ve reported, SBOMs are required from suppliers to the federal government per a May 12 executive order, and have been proposed for critical infrastructure by the U.S. Cybersecurity and Infrastructure Security Agency.
SBOMs would require software suppliers to document third-party software components embedded in their products, including open-source and commercial code. Components that are not up to date can contain code errors and vulnerabilities potentially usable by attackers to hijack a system, insert malware or disable operational technology (OT) or industrial control systems, as well as IT. Automobiles, medical devices and other increasingly software-controlled systems are also vulnerable.
The supply chain insecurity problem is widespread. The 2021 Open Source Security Risk Analysis Report, published by Synopsys in April, examined over 1,500 codebases. It found that 84 percent contained at least one vulnerability while 85 percent used open source components more than four years out of date. More than 90 percent contained open source components with customized licenses, license conflicts or no license. The percentage of codebases containing vulnerable open source components or high-risk vulnerabilities is increasing.
In May, Tencent Security Keen Lab found several exploitable vulnerabilities in a Mercedes-Benz infotainment system, including some in an outdated Linux kernel. The vulnerabilities could allow hackers to remotely control some car functions, such as anti-theft protection and interior lighting, but fortunately not the vehicle’s physical actions, such as braking or steering.
Development tools can also contain malicious code exploitable by hackers. For example, in April developers of Codecov’s Bash Uploader script, used in large-scale software projects, announced it had been compromised.
An error in Codecov’s Docker image creation process allowed an attacker to extract the needed credentials to modify the script without developer permission. For two months, malicious code in the publicly available software development tool potentially allowed attackers to steal sensitive information stored on developer users’ computers, then send it to a remote, third-party, non-Codecov server. That user information could include authentication credentials, tokens, keys, services, datastores and application code.
In addition to software components, some suggest including various types of services in an SBOM. “For example, if my application is a mobile app and I call out to the Google Maps API, that might be a component that I can describe in my SBOM,” said Steve Springett, senior security architect at Service Now, in a video interview with Risk-Based Security. “But primarily it’s about software and the dependency relationships about that software.”
Without an SBOM, it’s difficult to keep track of what exactly needs updating in a software product, and when. With an SBOM, developers can evaluate components for vulnerabilities and assess risk. Moreover, buyers of the finished products can do the same, avoiding code that contains known timebombs.
At least, that’s the idea.
SBOMs not (yet) a perfect solution
“SBOM is an interesting concept,” Ron Brash, director of cyber security insights for Verve Industrial Protection, told EE Times. “In theory it makes sense, but in practice it can be difficult for various reasons.”
Several problems stem from applying the concept of a hardware BOM to the very different software development process, Brash said. While a hardware BOM lists distinct components, each with its own part number, software builds have a potentially huge list of components, not to mention the need to document all the changes a developer may have made to them.
“And none of those permutations map back to a model number or code version,” said Brash. “It’s complicated, so we need some method that tells us the component is either plain vanilla or has been changed. Then how do you tie those software items to vulnerabilities?”
Listing vulnerabilities in an SBOM is also problematic. A vulnerability might not be exploitable, and it might not be compiled in, so information about compilers or flags is also needed. SBOMs provide some visibility, but “it’s no panacea unless all those complexities are included,” said Brash.
Ivan Speziale, a Nozomi Networks Labs’ security researcher, added: “The devil is in the details. A software deliverable is composed of many subcomponents, which in turn are composed of additional subcomponents. Where do you stop tracking those?
“Also, many software vulnerabilities may only be effective in specific scenarios, a concept that’s difficult if not impossible to translate to a software BOM,” Speziale added. “While a software BOM may help, it’s not likely to be the silver bullet that will solve software supply chain security issues.”
The vulnerabilities exploited in the Microsoft Exchange Server hacks were a supply chain problem, but as a third-party supplier Microsoft is at least a known entity, said Speziale. “We know Microsoft: We know they have scheduled updates and we know they have a thorough security process. The problem is with all the software you don’t know you’re running or how far it reaches into your organization or what the risks are.”
Ripple20, a vulnerability in a popular embedded TCP/IP software library, is a good example. It affected millions of connected OT, IT and Internet of Things devices last year. “Organizations were running the Ripple20 component but didn’t know about it because it was embedded in other software deliverables,” said Speziale.
Brash pointed out that while creating SBOMs for newer devices is relatively easy, doing so is highly problematic for older OT devices. “Source code could be lost, or maybe there’s no tooling anymore, or the company is gone, or programmers have retired,” he said. Depending on how they are used, SBOMs must be easy to incorporate into users’ workflows, for both developers and asset owners. “For example, I need to have a dashboard view that seamlessly shows me what the risks are, not just a list of software components. The latter wouldn’t help me as an asset owner, and probably doesn’t help the vendors, either.”
Starting in 2018, the National Telecommunications and Information Administration (NTIA) began helping industries develop SBOMs by defining them and identifying “existing standards that can be used to automatically convey SBOM data.” Progress has already been made with medical device manufacturers, and experiments are beginning in the automotive sector.
Section 4, “Enhancing Software Supply Chain Security,” of the White House May 12 executive order calls for the National Institute of Standards and Technology (NIST), the National Security Agency, and other agencies to identify or develop guidelines for enhancing software supply chain security over the course of this year. The guidelines will address SBOMs and the development environment, among other things.
In a statement, NIST said the guidelines will include standards, tools and best practices, including criteria for evaluating software security such as testing product source code, and for evaluating developers’ and suppliers’ security practices. NIST will request input from academia, government agencies and the private sector. Preliminary guidelines will be published by November 8, 2021.
This article was originally published on EE Times.
Ann R. Thryft has written about manufacturing- and electronics-related technologies for Design News, Test & Measurement World, EDN, RTC Magazine, COTS Journal, Nikkei Electronics Asia, Computer Design, and Electronic Buyers’ News. Sheâ€™s introduced readers to several emerging trends: industrial cybersecurity for operational technology, industrial-strength metals 3D printing, RFID, software-defined radio, early mobile phone architectures, open network server and switch/router architectures, and set-top box system design. At EBN Ann won two independently judged Editorial Excellence awards for Best Technology Feature. Currently, she is the industrial control & automation designline editor at EE Times. She holds a BA in Cultural Anthropology from Stanford University and a Certified Business Communicator certificate from the Business Marketing Association (formerly B/PAA).