With Log4j being such a ubiquitous library embedded in tens of millions applications across the Java ecosystem, it’s fairly obvious to understand why the Log4Shell CVE is being treated as a DEFCON 1-class situation. To add salt to the wound, many of the tools leveraged by Security, Ops, and Development teams are ill suited to respond to this crisis. Here at Contrast, we have already heard from several customers about how they are forced to run complicated, custom scripts, and advanced queries to understand what applications are running vulnerable versions of Log4j, if they’re using the vulnerable class, and if patching is even viable. Just recently Sándor Incze, CISO at CM.com said, “We were able to analyze whether our own built software would be vulnerable to the Log4j zero-day…” Mr. Incze is not alone in this regard. Software Composition Analysis (SCA) tools that live in the code repository are heavily over-reporting instances of log4j as evidenced by Contrast Co-Founder and Chief Scientist, Arshan Dabirsiaghi, where he presented data showing that only 37% of Java applications actually invoke log4j2.
Tools that present a deluge of irrelevant findings lead security teams to chase their developers to patch libraries that aren’t actually used by their application! In short, in the event of a zero-day incident response scenario, SCA tools need to enable teams to easily identify applications at risk, confirm which of them are actually vulnerable, and provide a quick means to institute some form of protection in place.
Enter Contrast and its cross-platform approach to Software Composition Analysis. Contrast SCA is uniquely suited to respond to the ongoing Log4Shell dilemma as it takes not only the third-party code into account, but how and if third-party libraries are invoked by custom code as well. In short, we take the ENTIRE application into account instead of enumerating libraries in isolation. Let’s get into the details.
Reason #1: Regardless of Software Lifecycle Stage, Contrast SCA Detects Vulnerable Versions of Log4j
Contrast SCA is a cross-platform service. Let’s clarify what that means in practice. As a built-in engine within the Contrast Platform, Contrast SCA provides software supply chain risk intelligence through multiple integration points across the software lifecycle. Developers can effortlessly assess for vulnerable third-party libraries within native pipelines via Contrast Scan, during routine software testing via Contrast Assess, and block attacks targeting vulnerable libraries via Contrast Protect. Contrast also extends into cloud-native environments like AWS Lambda by testing for vulnerable libraries in serverless functions.
“Ok, how does that help me with Log4Shell?” Glad you asked! In practice, Contrast SCA works across code, build, test, and production environments to help you identify where you have Log4j in use. Contrast SCA works in tandem with Contrast’s existing AST solutions to find vulnerable versions of Log4j1.x and Log4j2.x – no extra tooling required. Moreover, Contrast can protect against attacks against Log4j when patching or updating is not feasible.
Reason #2: Contrast SCA Flags if Log4j is Actually Used, Not Just Packaged in the Application
Embedding SCA solely at the repository level has its benefits in terms of instituting good open source hygiene among developers. However, within the context of the ongoing Log4Shell crisis, that creates more problems later down the line. SCA tools that only look at the repository report findings in libraries in direct and transitive dependencies that may or may not make it into the actual deployed artifact. Among those dependencies that do make it into production, only a portion of them are used. In fact, according to data from real-world running applications from Contrast Labs, 58% of Java applications package a vulnerable version of Log4j, only 37% actually use it!
If CISO offices expect a nimble response to zero-day events, their teams can’t afford to chase patches for applications that aren’t using the vulnerable component. Contrast SCA solves for this by taking the entire application into account. Instead of testing third-party libraries in isolation, Contrast SCA contextualizes how the running application invokes libraries to help teams determine if the library is actually used.
In responding to Log4Shell, this can be a crucial component in determining a remediation path within the developer CI/CD workflow.
Working in tandem with Contrast SCA, Contrast Scan can identify vulnerable versions of the log4j library and flag instances of log injections for both log4j1 and log4j2. Going one step further, Contrast SCA will even identify if the application is configured to use JMS Appender, a known attack vector within vulnerable versions of log4j1. Developers receive this feedback in real-time within their native CI tooling.
Contrast SCA will automatically inventory your third-party software assets – both COTS and OSS – during routine functional or QA testing. Contrast SCA’s runtime analysis identifies whether libraries are invoked by the running application – including vulnerable versions of JMS Appender. Without this insight, security and development teams waste precious time and resources fixing non-functional libraries pulled in during the build process. This intelligence enables developers to prioritize and focus remediation efforts on the Log4j libraries that pose real risk instead of chasing false positives.
Reason #3: Contrast SCA Catalogues Your Software Supply Chain IN REAL-TIME TO MAKE LOG4J QUERIES AS EASY AS A GOOGLE SEARCH
When stress levels are high, the thing that can make even the most seasoned Incident Response teams go into panic mode is when simple tasks become an exercise in attrition. Answering the question of “what’s in my application?” seems easy in theory, but in practice, it can be enough to turn your hair gray.
Contrast SCA benchmarks your third-party attack surface with a real time inventory of your open source and third-party software libraries. Security teams receive real-time alerts when new vulnerabilities are disclosed for deployed libraries and can export their software inventory into a standardized Software Bill of Materials. This makes it easy to query applications running log4j. There’s no custom scripts or APIs involved, it’s just a matter of typing in a few words in a search bar.
To better understand the embedded layers of risk within their software supply chain, Contrast SCA can generate a dependency tree using the Contrast CLI. With each new build, users can populate a dependency tree to understand which top level library is calling log4j and understand if they need to update, patch, or institute some sort of protection.
Conclusion: To Effectively Contain Log4Shell, You Need a Platform That Provides CONTEXT INTO IMPLEMENTING THE RIGHT FIXES
If there’s one thing you take away from this article, it’s this: in order to properly identify real risk in your third-party code, you also need to take into consideration how that code interacts within the rest of the application. Testing third-party libraries in a vacuum creates noise, siloed results, and just more confusion. It’s precisely this reason that Contrast takes a platform approach to Software Composition Analysis – providing third-party risk intelligence across all phases of the software lifecycle. As your code makes its way from build, to test, to production, your attack layer shifts and only by understanding how custom and third-party code interact with one another, can you effectively respond to zero-day events like Log4Shell.
The Log4j saga is still ongoing. As of the writing of this article, the Apache Foundation recommends updating to Log4j 2.17.0 and that could very well change in the days ahead. Where feasible, consider removing the Log4j library from applications where it’s packaged but not used during runtime. Contrast enables your team to take this more targeted remediation approach and institute the right protection measures when your team is stretched too thin.
