Such issues are likely to disproportionately affect small and medium businesses, he says—and make it nigh-on impossible to fix easily. Sonatype analysis has found that around 30 percent of the consumption of Log4j is from potentially vulnerable versions of the tool. “Some companies haven’t got the message, don’t have the materials, and don’t even know where to start,” says Fox. Sonatype is one of the companies that provide a scanning tool to identify the issue, if it exists. One client told them that without that, they’d have had to send out an email to 4,000 application owners they work with asking them to individually figure out if they were affected.
Part of the issue, of course, is the overreliance by for-profit businesses on open source, free software developed and maintained by a small, overstretched team of volunteers. Log4j’s issues aren’t the first—the Heartbleed bug that ravaged OpenSSL in 2014 is one high-profile example of a similar problem—and won’t be the last. “We wouldn’t buy products like cars or food from companies that had really terrible supply chain practices,” says Brian Fox, chief technology officer at Sonatype, a software supply chain management and security specialist. “Yet we’re doing it all the time with software.”
Companies who know they use Log4j and are on a fairly recent version of the utility have little to worry about and little to do. “That’s the unsexy answer to it: It actually can be very easy,” says Fox.
The problem emerges when companies don’t know they use Log4j, because it’s used in a small section of a brought-in application or tool they have no oversight over, and don’t know how to start looking for it. “It’s a bit like understanding what iron ore went into the steel that found its way into the piston in your car,” Glass says. “As a consumer, you have no chance of figuring that out.”
Log4j’s vulnerability, in a software library, makes it difficult to remedy, says Moussouris, because many organizations have to wait for the software providers to patch it themselves—something that can take time and testing. “Some organizations have higher technical skilled people inside of them that can work out different mitigations while they wait, but essentially, the majority of organizations rely on their vendors to produce high quality patches that include updated libraries or updated ingredients in those packages,” she says.
Yet companies big and small around the United States—and around the world—are having to move, and fast. One of them was Starling Bank, the UK-based challenger bank. Because its systems were largely built and coded in-house, they were able to detect quickly that their banking systems wouldn’t be affected by the Log4j vulnerability. “However, we also knew there might be potential vulnerabilities both in the third-party platforms that we use and in the library-originated code that we use to integrate them,” says Mark Rampton, the bank’s head of cybersecurity.
There were. “We quickly identified instances of Log4j code that were present in our third-party integrations that had been superseded by other logging frameworks,” he says. Starling removed those traces and prevented them from being used in the future. Simultaneously, the bank tasked its security operation center (SOC) with analyzing hundreds of thousands of events to see if Starling was being targeted by those looking for Log4j vulnerabilities. They weren’t, but are keeping an eye out. The efforts required are significant, but necessary, says Rampton. “We decided to take a ‘guilty until proven innocent’ approach, as the vulnerability was unravelling at such a pace that we couldn’t make any assumptions,” he says.
“I get where the FTC are trying to come from,” says Thornton-Trump. “They’re trying to encourage people to do vulnerability management. But it’s absolutely tone deaf to the actual threat risk that this vulnerability poses to many businesses. They’re basically making you press the panic button on something you don’t even know if you have at this point.”
More Great WIRED Stories