This past December, one of the worst software vulnerabilities in history emerged. With the Log4j CVE-2021-44228 vulnerability (a.k.a. Log4Shell), threat actors won the triple crown of exploits.

The scope was massive, affecting millions of consumer products, enterprise software and web applications. The threat was profound, giving malicious parties veritable free reign over compromised devices. And, to make matters worse, the exploit was painfully simple to execute, requiring just a single line of code.

The gravity of the situation was undeniable. And yet, over a month later, the Federal Trade Commission still felt compelled to issue a stern warning to those who had yet to remediate the flaw. Citing the Federal Trade Commission Act, the Gramm Leach Bliley Act and the 2019 Equifax ruling — which saw Equifax pay out $700 million in settlements — the FTC told companies that failing to protect user data could carry criminal and financial consequences. With an updated version of the offending JavaScript library already available, it’s only logical to ask why such a warning was even necessary in the first place.

At the heart of this disconnect is the reality that many organizations simply don’t know all of the components and assets making up their application ecosystem. They aren’t aware of all the third-party libraries and integrations they’re using, increasing risk and making prioritization that much more difficult. The good news: with automated tools, defined processes and documentation in place, strategies for getting ahead of threats like Log4j become clearer.

Make SBOMs part of standard operations

In May 2021, the Biden administration issued an executive order outlining best practices for vendors working with federal agencies. It underscored the need for Software Bills of Materials (SBOMs), which act as a window into an organization’s software ecosystem, including unseen component parts.

For complete coverage, an SBOM should include dependencies, packages, software development kits, agents and application programming interfaces (APIs). The order stresses that SBOMs are most effective when compiled in a searchable repository, so that locating and identifying vulnerabilities is a quick and efficient process.

In the case of vulnerabilities like Log4Shell, this takes on mission-critical importance, as teams must be able to rapidly and accurately determine if and where the vulnerable asset is in their supply chain. A searchable repository of SBOMs allows security teams to quickly identify which applications are affected, so that they can direct their energy and efforts toward actually fixing the problem, rather than scrambling to locate it. Unfortunately, a lot of organizations had no choice but to scramble in response to Log4Shell. This series of events has shown the immense value of visibility. It’s critical that more organizations make SBOMs an essential part of their security posture before the next major vulnerability is discovered.

Keep a close eye on web APIs

APIs add to an organization’s attack surface, so it’s important to know where they are used. Gartner estimates that roughly 90% of web apps will soon have more of their exposed attack surface area accounted for by APIs as opposed to their own interfaces. Indeed, in 2021, malicious traffic around APIs grew by nearly 350%. Despite these trends, API use only continues to grow.

Gone are the days of monolithic applications. Modern enterprise web applications are built with coupled services that communicate through APIs galore, and each component is a target for attackers if left unchecked. Pair that widened attack surface with the insane growth of APIs, and the need for strong API security is clear. Organizations need to cover their entire attack surface by implementing automated and accurate scans via user interfaces and APIs if they want to eliminate potential weak spots before they become problems.

Manage and reduce security debt

Put simply, security debt is an organization’s total inventory of unresolved security issues. These issues have a wide variety of sources, including knowledge gaps, inadequate tooling or cutting corners during testing in the race to market. And just like any other form of debt, security debt has a tendency to snowball.

Invicti research recently revealed that 70% of teams frequently, if not always, skip certain security steps during development. The research also found that it would take information technology (IT) teams an average of 112 hours per team member to resolve their current security debt. That’s two weeks dedicated to nothing but getting the organization out of the red.

Nonetheless, it’s a worthwhile endeavor. Because, as security leaders saw with Log4Shell, security debt can make it all the more difficult for an organization to respond to novel threats when they do arise. More importantly, the Log4j vulnerability showed security professionals that what’s secure one day might not be secure the next. While SBOMs help by bringing visibility into the software supply chain, eliminating and preventing security debt is a continuous, always-on process that requires intelligent, automated tooling.

Lessons learned from Log4Shell

When the alarm was sounded on Log4Shell, the cybersecurity community was thrown into full-blown crisis mode. Administrators the world over scrambled to determine the extent of their exposure and patch the vulnerability as quickly as possible. What the community soon realized (along with the FTC), is that answering those questions isn’t always so easy.

As security leaders continue to experience fallout from Log4Shell a full four months after its discovery, they have to take note that even a known target can be hard to combat when visibility is limited and defenses have been left to deteriorate. Log4Shell has been a long, difficult battle. But it isn’t the first, and it won’t be the last.

It’s important to understand that these practices are essential to a robust security posture in today’s threat landscape. Without a repository of SBOMs, little to no security debt, and API attack monitoring, security teams are left vulnerable to cyberattacks.

By enlisting the support of automated scans and other advanced application security tools, organizations can take the lessons they learned from the Log4j vulnerability and better their security posture.

This article originally ran in Today’s Cybersecurity Leader, a monthly cybersecurity-focused eNewsletter for security end users, brought to you by Security magazine. Subscribe here.