Asset Management, Application security

SBOM is an ingredient, not the whole recipe, in preventing the next Log4j breakdown

A view of the entrance into the Rapid7 offices. (Rapid7)

It's easy to see why software bills of materials (SBOM) are having their moment as networks race to mitigate the Log4j vulnerabilities.

The big question threatening the holiday plans of information security professionals right now is which applications in their environments are running Log4j. If vendors and developers handed out big lists of software dependencies, that would save Christmas, right?

Hold your horses (reindeer?) say security experts. SBOM is a great component of solving these problems, but is not the entire solution. Trying to solve a Log4Shell-type issue with SBOM alone, without the infrastructure to support it, would be like trying to solve the housing crisis with wood.

"It's just the list of ingredients. That's not a solution," said Gonda Lamberink, vice president of critical manufacturing security solutions at Fortress Information Security, which provides SBOM and HBOM risk analysis tools. "It needs to be built into asset management, software license management, checking for obsolescence, and any application development."

Log4j is a nearly omnipresent Java add-in that very well might exist in any Java application. Testing by hand to find vulnerable components will turn up several batch processes that run infrequently — testers may not find out for a while that software is vulnerable. Knowing which applications are vulnerable from the outset dramatically reduces the need for testing and the time to mitigate.

For that reason, the Biden administration made bills of materials a component of a recent executive order to shore up software supply chains. The Cybersecurity and Infrastructure Security Agency (CISA) and the National Telecommunications and Information Administration (NTIA) have been promoting SBOM since 2018, and in an odd moment of synchronicity, the Log4j debacle coincided with CISA's two-day SBOM-orama conference, which evangelized software transparency on Wednesday and Thursday of this week.

"It's easy for me to sit back and pontificate, 'Well, if this was magically a year from now and the government had been making SBOMs a mandatory thing for six months in the U.S. we would have known exactly where all the Log4js were across enterprises,'" said Bob Rudis, chief data security scientist at Rapid7 and a long time supporter of SBOMs. Rudis has vocally supported SBOM implementation in light of Log4j. "It's easy to say we wouldn't be doing any checks and you'd be able to find everything perfectly. It's easy for me to go say that and everyone else to go say that. But I think we're all living in a fantasy world if we think that SBOM is going to completely solve this problem."

SBOM would not identify what applications run in an environment, or where they are running. It would not force in-house application designers to abide by the SBOM requirements or guarantee that the SBOMs were kept track of in any usable way. Legacy products and shadow IT will not provide SBOM.

Rudis notes that another limiting factor is the lack of industrial-scale SBOM management software to keep systems organized.

"There's no MSExcel for SBOM," he said.

Just because an SBOM exists does not mean it is machine-readable. Sonatype Chief Technology Officer Brian Fox said came across SBOMs that were effectively just lists of components jammed into a PDF file.

"Can you imagine the company that has got 75,000 applications, even if they had PDFs from all the 300,000 individual components," he said.

There can sometimes be a feeling that with SBOM, patching a Log4j would be as simple as searching for all the current instances, replacing them, and then being done. That is not entirely true, said Fox. The Sonatype-run Maven Central calculates that consistently, day after day, more than half of all downloads of Log4j since the vulnerability emerged have been of vulnerable versions of the software.

It may not be a panacea, but everyone SC Media spoke with for this story agrees that SBOM is a worthy tool for the toolbox that would have dramatically increased the efficiency of patching for those prepared to use it. For all the difficulty in implementing a new system, Fox noted that many industries have these kinds of systems in place already. Automobiles, for example, can immediately recall the vehicles with a faulty air bag.

"So there is a world where we already can track the assets all the way down to the smallest part. We as consumers expect that of nearly everything we buy. The reality is it doesn't exist in software," Fox said.

Joe Uchill

Joe is a senior reporter at SC Weekly, focused on policy issues. He previously covered cybersecurity for Axios, The Hill and the Christian Science Monitor’s short-lived Passcode website.

Get daily email updates

SC Media's daily must-read of the most current and pressing daily news

By clicking the Subscribe button below, you agree to SC Media Terms and Conditions and Privacy Policy.