Government and security-conscious companies are increasingly requiring software vendors to provide them with software bills of material (SBOM), but in the hands of attackers, the list of components that make up an application could provide a blueprint for exploiting the code .
An attacker who determines what software a targeted company is running can retrieve the associated SBOM and analyze the application’s components for weaknesses, all without sending a single packet, says Larry Pesce, director for Product security research and analysis at software supply chain security company Finite State.
Today, attackers will often need to perform technical analysis, reverse engineer the source code, and check whether there are specific components known to be vulnerable in an exposed software application to find the vulnerable code. However, if the targeted company keeps SBOM publicly accessible, much of this information is already available, says Pesce, a former penetration tester of 20 years who plans to warn about the risks in a
presentation on “Evil SBOM” at the RSA Conference in May.
“As an adversary, you have to do a lot of this work upfront, but if companies are required to provide SBOM, publicly or to customers, and this… leaks into other repositories, you don’t have to do any work, for you it’s already been done,” he says. “So it’s kind of like, but not exactly, hitting the Easy button.”
SBOMs are proliferating rapidly, with more than half of companies now requiring any application to be accompanied by a list of components: a number that will reach 60% by next year, according to Gartner. Efforts to make SBOMs standard practice see transparency and visibility as first steps to help the software industry better protect your products. The concept has also spread to the critical infrastructure sector, where energy giant Southern Company has started a project
create a bill of material for all hardware, software and firmware at one of its substations in Mississippi.
Using SBOMs for malicious cyber attack purposes
Producing a detailed list of an application’s software components can have offensive implications, Pesce says. In his presentation, he will show that SBOMs have enough information to allow attackers to do so search for specific CVEs in an SBOM database and find a possibly vulnerable application. Even better for attackers, the SBOMs will also list other components and utilities on the device that the attacker could use to “live off the land” after the compromise, she says.
“Once a device is compromised… an SBOM can tell me what the device manufacturer left on that device that I could potentially use as a tool to start probing other networks,” he says.
The minimum baseline for SBOM data fields includes the vendor, component name and version, dependency relationships, and a timestamp of when the information was last updated,
per US Department of Commerce guidelines.
In fact, a comprehensive SBOM database could be used similarly to the Internet’s Shodan census: Defenders could use it to see their exposure, but attackers could use it to determine which applications might be vulnerable to a particular vulnerability, Pesce says.
“It would be a really interesting project, and honestly, I think we’ll probably see something like this, whether it’s a company creating a giant database or something the government mandates,” he says.
Red Team early and often
When Pesce mentioned his conversation with an SBOM advocate, he argued that his findings would make the fight to convince companies to adopt SBOM more difficult. However, Pesce argues that such concerns miss the point. Instead, application security teams should take to heart the adage that “red informs blue.”
“If you are an organization that consumes or generates SBOM, know that there will be people like me – or worse – who will use SBOM for evil purposes,” he says. “So use them yourself to do harm: put them as part of your overall vulnerability management program; put them as part of your pen testing program; put them as part of your secure development lifecycle – put them as part of everything your internal security programs.”
While software vendors might argue that SBOMs should only be shared with customers, limiting SBOMs will likely be a Herculean task. SBOMs will likely be released to the public, and the widespread availability of tools for generating SBOMs from binaries and source code will make limiting their publication a moot point.
“After working in this industry for quite a long time, we know that when something is private, it will eventually become public,” he says. “So there will always be someone leaking the information [or] someone will spend money on a commercial tool to generate SBOM on their own.”