Government and security-sensitive companies are increasingly requiring software makers to provide them with software bills-of-materials (SBOMs), but in the hands of attackers, the list of components that make up an application can provide a blueprint for exploiting the code.
An attacker who determines which software a targeted company is using can retrieve the associated SBOM and analyze the application’s components for weaknesses, all without sending a single packet, said Larry Pesce, director of 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 see if there are specific known vulnerable components in an exposed software application to find vulnerable code. But if the target company maintains SBOMs that are publicly accessible, then much of that information is already available, says Pesce, a former penetration tester with two decades of experience who plans to warn about the risks in a
presentation on “Evil SBOMs” at the RSA conference in May.
“As an adversary, you have to do a lot of that work up front, but if companies are required to provide SBOMs, either publicly or to customers, and that… leaks out to other repositories, you don’t have to do that.” If you do any work, it’s already done for you,” he says. “So it’s a bit like – but not exactly – pressing the Easy button.”
SBOMs are proliferating rapidly, with more than half of companies currently requiring each application to be accompanied by a list of components – a number that will reach 60% next year, according to Gartner. In efforts to make SBOMs a standard practice, transparency and visibility are seen as the first steps to help the software industry better protect their products. The concept has even spread to the critical infrastructure sector, where energy giant Southern Company has embarked on a project
create a bill of materials for all hardware, software and firmware at one of the substations in Mississippi.
Using SBOMs for malicious cyber attacks
Producing a detailed list of software components in an application can have offensive consequences, Pesce argues. In his presentation he will show that SBOMs have sufficient information to enable attackers to do so search for specific CVEs in a database of SBOMs and find an application that is likely vulnerable. Even better for attackers, SBOMs will also list other components and utilities on the device that the attacker could use to “live off the land” after a compromise, he says.
“Once I’ve compromised a device… an SBOM can tell me what the device manufacturer left on that device, which I could potentially use as a tool to investigate 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.
according to US Department of Commerce guidelines.
In effect, a comprehensive database of SBOMs could be used in a way similar to the Internet’s Shodan count: defenders could use it to see their exposure, but attackers could use it to determine which applications might be vulnerable for a certain vulnerability, says Pesce. say.
“That would be a really cool project, and honestly I think we’re probably going to see something like that — whether it’s a company running a massive database or whether it’s something that the government mandates,” he says.
Red team early and often
When Pesce brought up the conversation with an SBOM advocate, they argued that his conclusions would make the fight to get companies to adopt SBOMs more difficult. Yet Pesce argues that these concerns miss the point. Instead, application security teams should take the adage to heart: “Red informs Blue.”
“If you are an organization that consumes or generates SBOMs, know that there will be people like me – or worse – who will use SBOMs for evil,” he says. “So use them for evil yourself: bring them in as part of your overall vulnerability management program; bring them in as part of your pentesting program; bring them in as part of your secure development lifecycle – bring them in as part of all your internal security programs .”
While software makers might argue that SBOMs should only be shared with customers, limiting SBOMs will likely be a monumental task. SBOMs are likely to leak to the public, and the widespread availability of tools to generate SBOMs from binaries and from source code will make limiting their publication a moot point.
“After being in this business long enough, we know that if 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 SBOMs themselves.”