It’s 2022, and the cybersecurity community is now dealing with the long-term consequences of yet another software supply chain security disaster. After a year of application security zero-day fallout, the Log4j vulnerability (aka Log4Shell) served as a thematic bookend for 2021, bringing the year to a close in the same way that SolarWinds started it.
In too many ways to list, the real-world ramifications of these disasters educated enterprise IT personnel. But arguably, the most important takeaway is how much work many businesses still have to do to understand and control the code running behind the hood of their software portfolios. The Log4j event, like the SolarWinds incident, emphasized how many hidden software dependencies exist in enterprise software – and how difficult it is to eliminate crucial underlying faults when these dependencies aren’t well understood.
Much of today’s software is made up of prefabricated open source and third-party code due to the natural advancement of current development methodologies such as microservices and software componentization. Rather than spinning the wheel by writing new code for each app, software engineers simply mix and match existing libraries and packages for standard functionalities to construct most of the codebase that powers apps.
As per the “2021 Sonatype State of Software Supply Chain Report,” last year developers downloaded more than 2.2 trillion open source packages from online repositories for use in their projects, marking a 73 percent increase in developer downloads of open source components year over year.
When underlying components like Log4j are revealed to be weak, this technique makes development work faster and more predictable, producing a cascading risk impact. One of the significant challenges is that many premade libraries and open source projects are interdependent, resulting in a multi-layer chain of dependencies. This generates indirect dependencies that business defenders may find challenging to handle without much cooperation between many parties in an open source ecosystem like Apache’s.
According to Google’s Open Source Insights Team, 80 percent of Java packages impacted by the Apache Log4j library vulnerability cannot be upgraded directly, necessitating collaboration between multiple project teams to fix the bug. It means application security and development specialists will have to put in years of effort to eliminate the risk posed by this pervasive software flaw.
As these security and software professionals emerge from the Log4j catastrophe and begin to plan their objectives for 2022, security experts expect that the events of last year will spur a more general push for tracking Software Bills of Materials (SBoMs) and tighter dependency management rigor. SBoMs are similar to a software ingredient list in that they provide a defined approach for identifying components and dependencies in programs.
However, SBoM production and standards are in the process of maturing. Last year, the Biden administration included language in its cybersecurity executive order requiring software developers to sell to federal agencies to provide an SBoM. The National Telecommunications and Information Administration published a document detailing the minimum elements of an SBoM shortly after.
Meanwhile, industry organizations like the Linux Foundation are researching SBoM practices throughout the world. In order to manage risk in today’s software development settings, application security experts and cybersecurity executives must find a means to improve their SBoM tracking.
