Software bills of materials are having a moment.
Following an executive order issued by the Biden administration in May 2021, the software manifests, which outline the components and dependencies used both directly and indirectly to develop applications, are now required by the US government of all federal contractors. Given the low bar for producing a software bill of materials (SBOM) — an increasing variety of tools used during development can also produce one — the lists of application ingredients are proliferating. As a result, nearly half of all companies also now require SBOMs for any software. This number is expected to hit 60% by 2025, compared with less than 5% in 2022, according to data from market research firm Gartner.
The federal mandates have resulted in a rush to SBOMs and changes in how developers are documenting their software, says Stephen Magill, vice president of product innovation at Sonatype, a software development tools firm.
“The SBOM mandates that are coming out from government and from regulators provide an important incentive to up-level your development process and get a tool in place,” he says. “That’s a large part of why these regulations are coming in. It’s because the industry has not universally adopted this tooling, and open source continues to be a huge area of risk that, in many organizations, is just unmanaged.”
The rush to keep up with the government mandate is leading to fast evolution within the industry, as standards attempt to account for various ingredients that go into developing software. In June, for example, the Open Worldwide Application Security Project (OWASP) announced version 1.5 of its SBOM standard, CycloneDX, which now includes information on the machine learning (ML) models used in a particular application, as well as a measure of the quality of the SBOM.
While current SBOMs are often little more than lists of software components, the eventual goal is to give organizations a way to identify and document weaknesses in their software, says Thomas Pace, CEO of extended IoT security firm NetRise.
“Currently, end users have the issue of making decisions based on incomplete data, especially as it pertains to … devices running firmware, which is still a black box for the overwhelming majority of organizations,” he says. “Once they have these SBOMs, they can finally make data-driven decisions around the risk of the various devices, applications, and systems that they are utilizing.”
SPDX, CycloneDX, and SWID Standards
The US government recognizes three SBOM standards as meeting their minimum requirements: Software Identification (SWID) tags, the Software Package Data Exchange (SPDX), and CycloneDX.
In 2009, the International Standards Organization (ISO) created SWID tags as a way for organizations to track the software installed on their managed systems. More than a decade ago, the Linux Foundation created the SPDX to aid in the exchange of information about licensing. In 2017, OWASP created CycloneDX as a way to exchange data on SBOMs.
The three standards overlap significantly, but SPDX and CycloneDX seem to have the most momentum. There are also nuances between them — SPDX still has a greater focus on license management and the degree to which it supports machine readability. In practice, however, both consumers and providers of SBOMs should be able to work with the formats, says Fernando Montenegro, a senior principal analyst for cybersecurity at analyst firm Omdia, a sibling of Dark Reading.
“If you’re a developer, you can use SBOMs to more easily track the dependencies you will inherit in your own software as you add different modules. This will help you make better decisions about security,” he says. “If you’re a security team, those SBOMs provided by your vendors can help you understand what components are running on your environment … you can more easily prioritize remediation actions across your systems.”
Moving Beyond Awareness
Visibility and awareness are the primary benefits of SBOMs at present. CycloneDX SBOMs, for example, contain information on the software licenses, low-code services, and machine-learning models used in development, as well as information on vulnerability disclosure and annotations. Because 95% of vulnerabilities are not in the direct dependencies used to build software but in the indirect dependencies included by those components’ developers, most companies do not have good visibility into the risk of procured software, says Jamie Scott, a product manager for Endor Labs, a software risk management firm.
“People want to understand their software and inventory, so they can make informed risk management decisions, and they can do that reasonably well with SCA [software composition analysis] for the software that they create,” he says. “But for the software that they procure, they lack that visibility. So SBOMs are about getting visibility into your first- and third-party applications, so that you have a full software inventory.”
Yet SBOMs will increasingly become operationalized, says Zach Capers, senior security analyst at Capterra, a software market services firm. The company’s surveys have found that nearly half (49%) of companies require SBOMs as part of their current software procurement process.
“Just as software buyers can leverage SBOMs to improve visibility throughout their software supply chain, so too can software developers better track components used to develop their products,” he says. “We’re still in the early stages, but eventually you will learn about a newly discovered vulnerability and instantly be able to determine whether or not it lurks somewhere in your company’s software stack, thanks to SBOMs.”
The current set of changes are more about expanding the scope of what is documented using SBOMs, but eventually a variety of risk measures — and potential security controls — could be keyed to SBOMs, possibly leading to a regimen for software liability.
Machine Learning, Automation a Focus
When attackers began exploiting the Log4j vulnerabilities using the Log4Shell proof-of-concept, companies scrambled to determine whether the widespread open source component was in their environments.
When security professionals “think back to Log4Shell, part of the challenge for many organizations was answering whether or not they were using Log4j and were vulnerable,” says Josh Thorngren, head of developer advocacy at ForAllSecure, a security testing firm. “Organizations with SBOMs will be able to answer that question faster than those without, [and] over time we’ll start to see that variance and hear those reactions from security practitioners in the wild.”
In addition, software systems will likely automate their responses to known vulnerabilities. Companies will understand the vulnerabilities in their products, especially those from indirect dependencies, and — following the announcement of a new vulnerability — be able to implement controls, says NetRise’s Pace.
“Now you can implement a compensating control that detects traffic targeting that device specifically around those … available exploits, which basically all firewalls and intrusion detection systems are capable of today,” Pace says. “Without the SBOM, you are totally blind to these risks and are simply hoping the device manufacturers have developed a perfectly secure device, which of course is impossible.”
