SCSW The common analogy when talking about software bills of materials (SBOMs) is the list of ingredients found on food packages that lets consumers know what is in the potato chips they’re about to eat.
Likewise, an SBOM is an inventory of the components in a piece of software, a crucial tool at a time when applications are a collection of code from multiple sources, many from outside an organization’s development team.
“When it comes to a SBOM, it’s just as important [as the nutrition labels on food] because the risk is not to your physical health but the risk to your business,” Mark Lambert, vice president of products at ArmorCode, told The Register. “The risk that you’re potentially exposing your business to when you’re consuming software is that you don’t understand what it’s comprised of.”
When that happens, “you’re … exposing yourself to a vulnerability that is outside of your control. If you don’t have visibility into that, you can’t take precautions to make sure you’re not overly exposed.”
It’s why SBOMs over the past several years have become central to the expanding software supply chain management picture as threat levels increase. Through the growing use of open-source software and reusable software components, contributions from multiple sources, an accelerating code release tempo, and continuous integration and continuous delivery (CI/CD) pipelines, modern development has become faster and more complex.
“As the software supply chain gets more complicated, it is critical to know what open source you are indirectly utilizing as part of third-party libraries, services, APIs, or tools,” Lambert said.
Miscreants know that by injecting malicious code at any point in the development process or exploiting vulnerabilities in a component, they can move upstream and infect multiple sysytem, as seen in the SolarWinds breach in 2020 and the abuse of the Log4j flaw.
The need to know
SBOMs are also are a key point in the national cybersecurity plan developed by the Biden Administration and released this week. They not only tell organizations what components make up the software they’re bringing in, but also what code is in there.
SBOMs ensure “you know not only the ingredients in your software, but also the ingredients of those ingredients, sometimes referred to as transitive dependencies,” Donald Fischer, co-founder and CEO of Tidelift, told The Register. “In open source, many packages are calling on other packages, which you may or may not be aware that you are using, and SBOMs can help you fully understand these relationships.”
The discovery of the Apache Log4j flaw in December 2021 sent shockwaves around the tech world because the widely used logging tool was being broadly exploited to compromise vulnerable systems via a single injection of malicious code.
Its use was so broad that it touched most organizations, many of whom didn’t know they were affected. Within weeks of the vulnerability coming to light, there were reports of 10 million Log4j exploit attempts an hour.
“Log4j is used in the vast majority of software,” ArmorCode’s Lambert said, adding that it highlighted the need for SBOMs. “When [the flaw in] Log4j was identified, all of us were instantly exposed to the vulnerability. Log4j put everything into sharp focus. The problem has been there for a while.”
SBOMs come onto the scene
This latest renewed interest in SBOMs can, in a way, be traced back to efforts in 2018 by the National Telecommunications and Information Administration, a division of the US Department of Commerce, with standards on the matter published three years later. President Biden’s Executive Order in May 2021 called on the federal government to improve its IT security in the wake of SolarWinds and Log4j, both of which impacted government agencies.
“As with what typically occurs, the EO elevated the SBOM from a nice-to-have feature to a semi-mandatory solution that is now being evaluated throughout most governmental agencies and large enterprises,” TAG Cyber senior research analyst John Masserini writes in a blog post for ReversingLabs.
A challenge is that implementing and managing SBOMs is highly manual, which is bad news for admins and developers. An ongoing tension when talking about software supply chain security is ensuring that security demands don’t hinder the increasing speed of modern software development.
Automation is key
That’s why automating the SBOM process is important. NIST’s standard includes multiple elements, from the software component used and its supplier to version numbers and access to the component’s repository. Version levels must be evaluated against release levels, potential threats found, and risks determined.
“Unwinding large applications, from open-source operating systems, to in-house developed applications, to third-party ‘shrink-wrapped’ stacks is fraught with contextual challenges, inventory methods, and manual verification, all of which are prone to error,” Masserini writes.
While the process of identifying and reporting issues is codified, “it does not address the issue of manually maintaining such an inventory and consistently validating its contents,” he says.
Automation must be put into every step of the process, from generating and publishing SBOMs to ingesting them – and then bring vulnerability remediation into their current app security programs without having to adopt new workflows, Lambert says.
What to do with SBOMs
There are other considerations. SBOMs deliver a lot of information, but organizations need to decide how they’re going to use it. “SBOM” is a convenient catch-all acronym for a wider set of software supply chain issues, Tidelift’s Fischer said.
They’re also part of a larger cache of supply chain security technologies, such as SLSA (Supply chain Levels for Software Artifacts), a framework for ensuring software artifacts integrity throughout the supply chain that was born out of an internal Google tool and now is a industry project that includes such organizations as Intel, VMware, The Linux Foundation, and Cloud Native Computing Foundation.
“SBOMs by themselves are not a silver bullet,” he said. “We have to understand what they are good at and where they are less useful. They are good at helping you understand the components that go into your software. They are much less useful for actually improving the security profile of those components.”
There are a few key standard SBOM formats – Software Packet Data Exchange (SPDX), CycloneDX, and Software Identification (SWID) Tagging.
What’s needed now is a secure and centralized vulnerability exchange where companies can share information about flaws, Lambert said. Having the SBOM data is useful, but if a vulnerability is uncovered, communication about it is still point-to-point and that information needs to be shared more quickly and widely,h e opined.
Pay the maintainers
Another emerging issue is that SBOMs and the like mean more work for those maintaining the open-source software that is used in most applications, Fischer said. And most of the maintainers – 60 percent, according to Fischer – are unpaid, essentially volunteers.
They “generally lack the alignment, much less the incentive, to address long checklists of secure development practices,” he said. “Against a backdrop of increasing government and industry attention on cybersecurity in the wake of high-profile vulnerabilities like those that impacted SolarWinds and Log4j, demands on these volunteer maintainers are increasing exponentially.”
Improving security requires tools – like SBOMs – and people. It’s time to start paying the open-source maintainers like companies do anyone else who is responsible for software security.
SBOMs, like many of the tools use for security the supply chain, are still relatively new and need maturing. Given the speed at which miscreants are coming up with ways to attack the supply chain, the faster that maturing happens, the better.
“SBOM has a way to go, but it is a good solution,” Lambert said. “Having a standard is not bad. Having no standards is a problem.” ®
