Shifting Log4j Discovery Right

You hear a lot about shifting your application security (AppSec) left – in other words, shifting AppSec to the beginning of the software development lifecycle (SDLC). While we firmly believe that you should continue scanning in development environments, that doesn’t mean that you should neglect applications that have been deployed to or staged in runtime environments.  Runtime presents a unique set of challenges – misconfigurations, logic errors and the like that can’t be identified in a static or software composition analysis scan. If you aren’t testing for vulnerabilities at runtime, you are risking a potential breach of a different kind. As Chris Wysopal, our co-founder and CTO, frequently emphasizes:

 In a shift left world, shifting right is more important than ever.

There are many examples that warrant shifting both left and right – especially during times of heightened alert like the current political unrest. President Biden recently addressed our nation on cybersecurity, stating: 

This is a critical moment to accelerate our work to improve domestic cybersecurity and bolster our national resilience ... My Administration will continue to use every tool to deter, disrupt, and if necessary, respond to cyberattacks against critical infrastructure. But the Federal Government can’t defend against this threat alone. Most of America’s critical infrastructure is owned and operated by the private sector and critical infrastructure owners and operators must accelerate efforts to lock their digital doors ... If you have not already done so, I urge our private sector partners to harden your cyber defenses immediately.

In these circumstances, using resources to find errors in code already in production and fixing them is more important than fixing flaws in your next release.

The recent zero-day vulnerability in Log4j 2.x reported on December 9, 2021 is also a prime example of the need to shift right. Log4j is a Java-based logging utility used by developers to keep track of what happens in their software applications or online services. It’s basically a way of logging the activity of a system or application.  

Most organizations that deploy or use Java applications or hardware running Log4j 2.x were affected by this vulnerability. In fact, our customer data shows that 88 percent of organizations with over 100 apps use Log4j.   

In an attempt to stay ahead of the rising tide of Log4j vulnerabilities, many organizations have been scanning their codebases for log4shell – the vulnerability in Log4j utility that allows a bad actor to launch a remote code execution attack – in the development phase. However, in the haste to find and remediate log4shell in those libraries, they shouldn’t overlook the fact that log4shell can also appear in runtime environments. If your security teams aren’t leveraging dynamic analysis, your organization could still be vulnerable. 

That said, not all dynamic analysis scanning tools (DAST) are made equal. For example, most DAST products can identify a runtime log4shell vulnerability, but can’t indicate where in the codebase to fix the issue or help identify the development team responsible for that application.  

To solve this problem, the Veracode Dynamic Analysis team worked around the clock to release a detection method to uncover vulnerabilities in a runtime environment without the added risk – including the most recent log4shell. Veracode's Dynamic Analysis ISM tool allows teams to run a scan behind the firewall on staged or pre-production environments. This allows security teams to test applications and APIs at “runtime” without altering or deleting the production data or slowing down production systems.  

Scan applications for log4shell in a runtime environment   

• Veracode DAST can now verify Java applications that are still vulnerable to log4shell remote code execution attacks running in a customer environment.  
• The Log4j scan runs as part of Veracode DAST for both web applications and APIs, so there is no need for additional tests. 
• The Dynamic Analysis engine allows security teams to conduct real-world, simulated attacks. 

What does this feature enable you to do? 

• Automate runtime aspects of the log4jshell attack without injecting servers with malicious code. 
• Surface applications that are still vulnerable to log4shell. 
• See the detailed results of the analysis presented as a vulnerability in the Veracode Dynamic Analysis triage view.  
• Target impacted applications for immediate remediation. 
• Save time and avoid the frustration of having to manually find log4shell vulnerabilities. 

Are you ready to shift Log4j discovery right? Learn more by visiting our dynamic analysis page.