How We Handled the Log4j Security Vulnerability

"The log4j vulnerability is the most serious vulnerability I have seen in my decades-long career", Jen Easterly US Cybersecurity and Infrastructure Security Agency Director 

Log4j is a Java-based logging utility part of the Apache logging services. This is a popular logging tool used in tens of thousands of software packages. Google estimates that 8% of Maven Central Repository was affected with about 7000 artifacts directly dependent on log4j (either a version of log4j-core or log4j-api). Every major software company went into crisis mode, they were trying to figure out how their products could possibly be affected and if so how they were going to patch the vulnerability. Lattix being a Java-based application also needed to scan its codebase.

We Used Lattix Architect To Find and Plan Our Log4j Patch

Development teams generally have a lack of visibility into their dependencies which makes patching a security vulnerability like log4j more difficult. Since the Lattix development team uses Lattix Architect we have a complete understanding of all of our dependencies. How did we find and plan our fix for the log4j vulnerability?

1. We loaded Lattix codebase into Lattix Architect. Since we run our codebase nightly in a Gitlab pipeline, we already had an up-to-date snapshot of the codebase and could easily see the dependencies in a Dependency Structure Matrix.

2. Then we checked for the usage of Log4j in the Lattix codebase. This is easy with Lattix Architect. The usage tab enables a very detailed analysis and drill-down of dependencies. The usage tab contains two panes - a Used By pane at the top and a Uses pane at the bottom. The uses pane shows all the external subsystems. You can then drill down further by selecting an external subsystem (in Java it shows everything based on namespaces). 

We were able to determine that Lattix did use log4j, but it was an older version of log4j which did not have the current security vulnerability. Since we were using an older version of log4j it did have other vulnerabilities so we decided to upgrade to the latest version anyway.

3. Next we estimated how much work it would be to create a patch. Again in the usage tab, the Used By pane lists all the users of the log4j external dependency within the Lattix codebase. 

This lets us know everywhere we need to make changes in the codebase. So we have a quick snapshot of how much work it will be to patch this vulnerability. This also gives us the confidence that we have found all instances in the codebase that use log4j. Later this view will also allow us to plan our testing to make sure that after the upgrade of log4j all the logging is still working as expected. 

Conclusion

Lattix Architect allowed us to quickly (less than 10 minutes) find and scope the problem with log4j in our codebase. We were able to accurately estimate how long it would take to fix and release a patch to Lattix Architect. We also had the confidence that we had all the instances of log4j and could test everything that was needed.