Why Developers Should Care About Log4j

On Dec. 9, 2021, a vulnerability was discovered in the popular Log4j Java logging library. The vulnerability was quickly dubbed Log4Shell. In a nutshell, an attacker can exploit the component to introduce a particular string, allowing them to execute code remotely and arbitrarily in the target application. Pretty wild stuff, right?

It is almost impossible to imagine how such an attack will not affect user experience and metrics like mean time to acknowledge (MTTA) and mean time to resolve (MTTR). When those metrics start dragging out, developers have to divert considerable resources to gaining observability, finding possible exploits, and troubleshooting vulnerabilities. If a few years ago cybersecurity was not an immediate concern in software development, that is very quickly changing because users are interacting directly with these applications to get things done.

How Log4j Affects Developers
The Log4j vulnerability is the kind of vulnerability that, when exploited, affects developers first because it's their code that is being targeted. Organizations may not even know they are experiencing a cyberattack until there is an impact on user experience, and the responsibility for monitoring user experience typically falls on the developers, site reliability engineers, and DevOps teams.

This vulnerability is particularly concerning because of the massive use of the Log4j libraries by developers, including some of the most popular software applications delivered by companies like Apple and Microsoft. The distributed nature of software means applications may be affected even if they don't use Log4j directly, since they may have other dependencies that rely on the affected library. An attack would drill deep into a software's architecture.

Because software development teams are often among the first people to experience the effects of an intrusion, DevOps and developer teams will very likely be charged to prepare for and mitigate cyberattacks. However, even before that day comes — and it will come — the key performance indicators (KPIs) that measure the productivity and success of software development teams will be directly impacted.

How to Find Clues to Log4Shell Vulnerabilities
Due to the nature of modern software architecture, it is almost impossible to know whether a certain application is impacted by this vulnerability. Cloud infrastructure is dispersed. Software applications are composed of microservices and other third-party components that, in turn, are composed of their own smaller third-party components. Therefore, unless software development teams can gain full visibility into how their data flows to and through their dependencies, you can never truly be sure if you are affected by this vulnerability.

One thing you can do is check your stack: Log4j versions 2.0-beta9 to 2.14.1 (inclusive) are vulnerable. Use of specific JDK versions (6u211+, 7u201+, 8u191+, and 11.0.1+) makes exploitation more challenging, but they are still vulnerable.

However, as I mentioned, due to the distributed nature of cloud computing, it's a bit more complicated to find Log4Shell. So you must ask yourself: If a vulnerability exists in the wild but I can't find it, does it really exist somewhere in my stack? The answer is: Probably.

This is where modern observability solutions come into play. Observability tools are built to help R&D teams better monitor distributed tech stacks and shed light on the "black boxes" that software applications are dependent on.

Distributed environments are like a car powered by 50 different engines. The speed your car can harness is incredible. However, if it breaks down, you would need to pop up 50 different hoods to find the engine causing the problem. The same is true for cyberattacks on distributed environments. Instead of defending one server from attacks, now a hacker has 50 services to target, making your application more vulnerable with 50 potential targets to manage, monitor, and defend. Observability solves that issue by pointing you in the right direction of the problem hood.

If you already have observability solutions monitoring your serverless, microservice, or other types of cloud-native or cloud-hybrid application, you should use them to find vulnerabilities in your code or misconfigurations in access.

Granted, observability solutions are technically not cybersecurity solutions. They are not tasked with finding cyberattack surfaces and alerting you on them. But they can act as the first line of defense because they can provide the first alert of downtime or diminished user experience, which could be caused by a cyberattack like a distributed denial-of-service attack.