Assembling an ingredients list for software
- By Karen Epper Hoffman
- Aug 24, 2018
LAS VEGAS -- Any new dieter will attest, reading the ingredient label on the package is the best way to understand how healthy (or unhealthy) a food is. Similarly, a new initiative from the Department of Commerce aims to help enterprise software users get a better handle on the “ingredients” that in the software they might be using so they can better understand its potential security risks associated.
Speaking at the Black Hat conference earlier this month, Allan Friedman, director of cybersecurity for the National Telecommunications and Information Administration, discussed how his unit is working to develop a “software bill of materials,” a list of ingredients for business software products.
In his presentation, “How I Learned to Stop Worrying and Love the SBOM,” Friedman detailed the multi-stakeholder initiative launched this summer. “[Business] software is not hewn from marble by gifted sculptors,” he said, pointing out that most software is, in fact, an amalgamation of various pieces of code from third parties across the globe.
Since these software components often hail from a wide variety of sources, it can be difficult for enterprise developers to properly understand the implicit security risks in their systems. And, as Friedman pointed out, this extends not only to business software, but also to industrial software and code used in medical devices. “Whether you build something or buy it, you want to know what’s in it,” he said.
However, despite the simplicity of this concept, the SBOM has been met with both apathy and hostility, especially in policy circles, according to Friedman. But, despite SBOM’s controversial nature, it could potentially revolutionize the information security industry, especially as enterprise software enters the internet-of-things phase of development, where virtually all electronic equipment is IP-connected and therefore accessible to access or attack.
“For business customers, having a ‘list of ingredients’ helps greatly with the threat discussion,” Friedman pointed out. It would give them information about the country or company the code came from as well as if the code might be outdated, in need of patching or reviewed for flaws. “It allows the [enterprise user] to take the steps needed to fix old software… [and] it helps with [software] end-of-life, especially with older software libraries.”
The goal of the SBOM initiative is “for software and IoT vendors to share details on the underlying components, libraries and dependencies with enterprise customer," Friedman said. "This transparency can catalyze a more efficient market for security by allowing vendors to signal quality and giving enterprise customers key knowledge -- you can’t defend what you don't know about." It also promotes the sharing of security responsibilities, giving enterprises more insight into what is running on their networks, he added.
Other challenges exist, however. It "complicates existing relationships between vendor and customer," he said. It may also put software component vendors in the position of assuring that a particular potential vulnerability will not affect a specific enterprise software. Finally, there is no way to compile a “complete” SBOM due to the lack of information from third parties. However, as Friedman pointed out, “If you know most of what’s in a product, you’re much further ahead than knowing nothing.”
Karen Epper Hoffman is a freelance writer based in the Seattle area.