According to research from Google’s Open Source Insights Team, the Apache Log4j vulnerabilities affect 4% of the projects in the Java ecosystem – over 17,000 packages in the Mavern Central repository alone.

Log4j is a popular library that provides logging services to many thousands of Java based applications. Earlier this month security teams and system admins around the world were scrambling after a critical severity vulnerability was disclosed in the library.  One of the main challenges faced by Security Managers trying to assess and manage this threat is the lack of visibility as to whether Log4j is even used within their network as it is not something you would install directly – it is a component that is pulled into other projects and applications.

Modern software projects make extensive use of external components and libraries to implement utility functions – such as logging.  When a new version of the project is built (or compiled) these external components are identified in configuration files as dependencies and automatically included.  When an external component is named directly, this is known as a direct dependency.  However, those direct dependencies may themselves pull in other components and open source libraries through their own dependencies – and these can iterate several times until all the dependencies and their dependencies have been gathered into the project.

According to the Google team’s research, the majority of the uses of Log4j happen five levels down the dependency tree – and some up to nine levels down – meaning it is not at all clear or obvious to developers or security managers that Log4j is even in use.  In order for a fixed version of Log4j to be included into a project, it is necessary for the package maintainers of those dependent components to update their own dependency requirements to explicitly pull in the fixed version in order for it to be included.  This is a not well known feature of the Java ecosystem – updated versions of packages are not automatically included as they often are in other ecosystems such as npm.

Googles Open Source Insights provides a way to identify the code that your code depends on, tracking nearly 2 million packages and their dependencies since its launch in October this year.