Log4Shell Vulnerability: How DevSecOps Pros Can Mitigate Risk

A critical vulnerability in the open-source Apache Log4j library that impacts countless applications and systems around the world was publicly reported on Dec. 10.

According to the U.S. Cybersecurity & Infrastructure Security Agency (CISA), the Log4j vulnerability, known as Log4Shell, could enable "an unauthenticated remote actor [to] exploit this vulnerability to take control of an affected system."

The vulnerability, which is also known as CVE-2021-44228, has already been patched by the open-source project, but it is up to organizations, application providers and developers to deploy the patch – that is, if they even know they are using the vulnerable library in the first place.

While the Log4j Log4Shell vulnerability is severe, it is not the first, nor will it likely be the last, that involves some form of underlying code library that is widely used. 

Patching the vulnerable component in production as well as deploying a network or cloud-based Web Application Firewall (WAF) service are both forms of mitigation that can help. At a deeper level, there are a number of best practices that organizations and DevSecOps teams can employ to limit the risk of CVE-2021-44228 and whatever vulnerability like it comes next.

Following are a few key recommendations for DevSecOps professionals to help build the resilience necessary to prevent and mitigate flaws like CVE-2021-44228 from having a severe impact.

Bridge DevOps with SecOps

With an active threat like the Log4Shell vulnerability, security operations teams need to actively collaborate with DevOps teams. A common approach in DevSecOps is to “shift left” – adding security earlier in the development process. With an active threat, the issue is in code and it is also in production, requiring a more comprehensive approach.

"Bridge the left side of CI/CD with the right, truly bridging Dev and SecOps," Sandeep Lahane, founder and CEO at Deepfence, told ITPro Today. "Thousands of vulnerabilities generated during CI/CD scans help little in times like this as Ops has to patch potentially thousands of nodes under intense time pressure."

Lahane suggests that DevSecOps teams augment their capabilities with runtime tools that use traffic context to enumerate, visualize and seal off attack paths.

Use Application Security Testing to Identify Common Flaws

The Log4Shell vulnerability is a common type of flaw that could have been identified during development had the code been scanned with the right type of tool.

According to Jeff Williams, cofounder and CTO at Contrast Security, application security testing (AST) prevents developers from making the kinds of mistakes that lead to exploitability.

"In this case, developers didn’t validate or escape data before logging it, a problem called log-injection," Williams told ITPro Today. "Eliminating this problem would have stopped Log4Shell attacks from reaching the vulnerable library."

Utilize Software Composition Analysis

From a DevSecOps standpoint, limiting risk from Log4Shell and future vulnerabilities like it means knowing what is in your software and having the automation in place to easily upgrade, according to Forrester analyst Sandy Carielli.

Carielli said that to understand and control what software is present in an organization's applications, DevSecOps teams need to integrate development pipelines with tooling that:

"Software composition analysis [SCA] is the tool that security teams use to understand the open-source components, and often commercial components too, in your software." Carielli told ITPro Today. "A well-implemented SCA solution will integrate with the CI/CD pipeline, including with the source code repository, to block known malicious components, identify vulnerable libraries and how they are used, and recommend and help automate upgrades and patches."

Many SCA technologies today are extending into broader supply chain issues, recommending upgrades when components are stale, out of date or poorly maintained, she added. Many SCA tools also now generate and analyze software bills of materials (SBOMs).

"In the case of Log4j, a well-integrated SCA tool should find all vulnerable instances of Log4j, prioritize them based on how your product calls the component, recommend the upgrade to the fixed version and provide the automation to make that upgrade as seamless as possible – and do all of that in the developer’s native environment," Carielli said.