Log4j Highlights Need for Better Handle on Software Dependencies

It's a new year and the cybersecurity community now faces the long-term consequences of yet another software supply chain security nightmare. After a year full of application security zero-day fallout, the Log4j vulnerability debacle (also referred to as Log4Shell) was like a thematic bookend for 2021 that closed out the year much in the way SolarWinds started it.

The real-world consequences of these incidents schooled enterprise IT teams in too many ways to count. But perhaps the most important lesson to bubble up is how much work many organizations need to do to truly understand and manage what code is running under the hood across their software portfolios. Like the SolarWinds incident before it, the Log4j fiasco highlighted how many hidden software dependencies exist in enterprise software — and how hard it is to stamp out critical underlying flaws when these dependencies aren't sufficiently understood.

A big part of this comes from the natural progression of modern development techniques, including microservices and componentization of software, whereby much of today's software is made up of prefabricated open source and third-party code. Rather than reinventing the wheel by creating a new body of code for each app they develop, software engineers essentially mix-and-match existing libraries and packages for common functions to create the bulk of the codebase that runs applications.

According to the "2021 Sonatype State of Software Supply Chain Report," last year developers around the world pulled more than 2.2 trillion open source packages from online repositories to use in their work, representing a 73% year-over-year growth in developer downloads of open source components.

This approach makes development work faster and more predictable, but it also creates a cascading risk effect when underlying components such as Log4j are found to be vulnerable. One of the big issues is that many prefabricated libraries and open source projects are dependent on one another, creating a chain of dependencies that can go several layers deep. This creates a situation in which there are indirect dependencies that can be difficult for enterprise defenders to address without a lot of coordination between various players in an open source ecosystem such as Apache's.

According to the latest studies by Google's Open Source Insights Team, 80% of Java packages affected by the vulnerability in the Apache Log4j library cannot be updated directly and will require coordination between different project teams to address the flaw. This spells years of work for application security and development professionals to stamp out the risk from this widespread software weakness.

As these security and software professionals emerge from the crisis mode of Log4j and begin to chart their priorities for 2022, security pundits hope the events of last year can drive a more widespread push for tracking software bills of material (SBoMs) and greater discipline in dependency management.

SBoMs are like an ingredient list for software, providing a formalized method for identifying components used and dependencies in applications, explains Tomislav Pericin, chief software architect for ReversingLabs.

"SBoM is the essential way of knowing about dependencies in software packages," says Pericin.

"The key value is the ability to create a software inventory so that when an attack or vulnerability happens you have a place where you can ask 'Where is it located?,' 'Where can I get an update?,' [and] 'What do I have to take offline?' Of course, the devil is in the details. Many SBoMs are still manually created and managed. Given the frequency of software changes and the quantity of applications, it can be difficult for individuals to maintain and keep SBoMs up to date." 

However, the maturation of SBoM creation and standardization is underway. Last year, the Biden administration included language in its executive order on cybersecurity to require software developers selling to federal agencies to provide an SBoM for their software, and soon thereafter the National Telecommunications and Information Administration published a document detailing the minimum elements of an SBoM. Meantime, industry groups such as the Linux Foundation are currently running studies to better understand SBoM practices globally. The upshot is that application security professionals and cybersecurity leaders need to find a way to hone their SBoM tracking in order to manage risk in in today's software development environments.

"Given the widespread use of open source and other third-party components in modern applications," says Nicholas Sciberras, head of engineering at Invicti’s Acunetix, "SBoMs are a foundational element of cyber resilience."