Perhaps, in a long-game way, we should be giving thanks for Log4Shell, the catastrophic vulnerability in the open-source Apache logging library Log4j. Yes, every bad thing you’ve heard about it is true. It’s trivially easy to exploit. It puts hundreds of millions to billions of applications at risk. Within days of it becoming public last month, attacks exploiting it were coming every second. It has been labeled a recipe for “an internet meltdown.”

U.S. Cybersecurity and Infrastructure Security Agency Director Jen Easterly called it “one of the most serious I’ve seen in my entire career, if not the most serious.” Michael White, technical director and principal architect with the Synopsys Software Integrity Group, views it as “a classic iceberg. There are 3 billion devices that run Java and Log4j is a very common logging library,” he said.

But, but, but … amid the necessary feverish scramble to patch or “vaccinate” against Log4Shell, SBOM (Software Bill of Materials) has suddenly become the hottest acronym in cybersecurity. Which, in an industry littered with hundreds of them, is saying something.

And that could be a very good thing for the long-term security of software because while keeping a rigorous inventory of your software supply chain won’t magically make your software bulletproof, it will help make it a vastly more difficult target.

SBOMs are not a new concept. Experts have been crusading for them for the better part of a decade. Two major annual reports from Synopsys—the “Building Security In Maturity Model” and the “Open Source Security and Risk Analysis”—have consistently stressed the importance of creating and maintaining a SBOM. But that message has been slow to gain mainstream traction, perhaps, in part, because of the visible supply chain problem—the one illustrated by a fleet of container ships stuck waiting off the southern California coast—is so much more obvious and makes for such compelling TV images.

Unfortunately, the software supply chain problem is just as serious—perhaps more serious because it keeps getting worse. It won’t diminish now that the holiday rush is over. And it’s not caused because products aren’t available. There are no empty shelves at the “software component store.” There’s an almost unlimited supply of components you can use to help your app, your website, your network, and your system do just about anything you want them to do. The problem is that while a software supply chain isn’t visible, its vulnerabilities can affect the real world.

Software Risks Are Business Risks

As we all know, software is everywhere and in everything because it powers innovation. Every business is a software business. But unpatched vulnerabilities can lead to what is now a familiar parade of horribles: the hijacking of systems, data leaks (and therefore theft of sensitive data), denial-of-service attacks, system crashes, theft of everything from identity to financial data and intellectual property, millions lost to ransomware, critical infrastructure damaged or shut down, and more.

In short, if your software is at risk, your business is at risk. Log4Shell is only the latest example of that. And attacks exploiting vulnerabilities like it are easier if organizations don’t know they need to patch them. As has been said thousands of times at security conferences like RSAC, you can’t protect something you don’t know you have.

So, if Log4Shell serves as the wake-up call that’s more potent than all the previous impotent wake-up calls, it’s worth giving thanks for it. Because too many organizations still aren’t maintaining a comprehensive SBOM. They may think they know what components they’re using, but they haven’t done a rigorous inventory of what those components are using. Those dependencies can go multiple levels deep and exponentially increase the number of software components that need to be tracked and, frequently, updated.

Securing Your Software Supply Chain

The good news is there are numerous resources available to help organizations create and maintain a SBOM, including automated tools and detailed advice from government and private sector associations. Among them, the National Telecommunications and Information Administration, within the Department of Commerce, has a section of its website devoted to everything an organization needs to understand a SBOM, including an extensive Q&A. Also, the federal Cyber Information Security Agency hosted a virtual conference titled “SBOM-a-rama” on December 15 and 16, in which SBOMs were described as “a key building block in software security and software supply chain risk management.”

A couple of caveats: A single SBOM isn’t enough. While a good software composition analysis tool can help find open-source components, organizations also need to track whatever proprietary code they create and should demand SBOMs from the vendors of any third-party software they buy. And SBOMs aren’t the only things an organization needs to protect its software.

Layered security that includes access controls, input and output validation, logging, monitoring, and anomaly detection ought to be mandatory as well. But if you want to trust your software—and you should—an SBOM is a great way to start.