Responding to Log4Shell, the Log4j zero-day that disrupted the lives of security teams around the globe, is not a one weekend or one week event. While organizations may have put in place immediate responses to try to prevent exploits, the problem won’t be resolved until all of the applications that use Log4j have been remediated. This will require a long term response that remediates the impacted applications while preventing any more vulnerable components from making it through to production or being delivered to customers.
Since the Log4shell vulnerability disclosure, we’ve seen a huge interest in our open source projects, Syft and Grype. These tools are simple yet powerful CLI utilities which help you generate a Software Bill of Materials (SBOM) for your software artifacts (Syft) so you can see if you are using Log4j and notify you if they are vulnerable (Grype). Our VP of Security, Josh Bressers, wrote an Infoworld article explaining how you can get going with them quickly.
Syft and Grype are very convenient for ephemeral, one time scans but with a fast moving situation and new versions of Log4j coming out quickly to address the vulnerability (we’ve already seen two), tracking, enforcing and managing the SBOMs and vulnerability data they generate can quickly become challenging. Anchore Enterprise provides users with a number of features that both help to reduce the pain of the current response frenzy and help you over the long haul get to a place where the vulnerability has been fully remediated.
Detecting Log4Shell at Scale
Applications containing Log4j may be going through your development pipeline, sitting in your registry, or actively running in Kubernetes. Anchore Enterprise customers already have all of this information about the possible locations of the vulnerable package in a single repository so they can easily search across their entire environments to assess the impact.
Anchore Enterprise customers already get a fully supported version of the functionality in Syft and Grype combined into a single tool called AnchoreCTL. Whether used on the command line on a desktop or integrated into your CI/CD pipelines, AnchoreCTL pushes all of the SBOM data to Anchore Enterprise centralized data store. Combined with data that Anchore Enterprise gathers from artifact registries or Kubernetes environments, all SBOM data is managed and accessible in a single place.
Not only does this allow security teams to detect whether vulnerable versions of Log4j are being used anywhere across their environments but also allows them to check when new versions of Log4j are being deployed and put into production by developers.
Many CEOs and Boards of Directors are demanding daily updates from the CISO and security teams on the business impact of the Log4j vulnerability and Anchore Enterprise’s reporting system is allowing security and response teams to accurately report on how vulnerable they are to the ongoing issue.
Using Policies for Enforcement at Scale
While identifying if and where you are vulnerable is the essential first step to triage the problem, customers quickly need to reduce risk. Anchore Enterprise contains a sophisticated policy engine that can provide a “stop” signal to the platforms in your development environment. By default, the out-of-the-box policies in Anchore Enterprise contain a rule disallowing critical CVEs so all customers already received necessary protections as soon as the issue was flagged in public databases on December 9, even if they had not yet crafted a specific response.
For users who are using AnchoreCTL to scan builds in their CI/CD systems, as soon as the policy rule about critical CVEs was triggered, build and deployment jobs would have been halted for affected software. Going further along the deployment process, users who had Anchore Enterprise connected to Anchore’s Kubernetes Admission Controller, would have also been unable to deploy vulnerable applications as a result of the policy rule.
Beyond the default policies provided by Anchore Enterprise, customizing more granular policy rules can help your organization to further pinpoint your efforts. For example, users may run very old versions of Log4j that are not vulnerable to the Log4Shell exploit. Users can easily add an access list rule in Anchore Enterprise to disallow the impacted versions (2.0 to 2.15) but allow others (versions lower than 2.0) to ensure the dragnet doesn’t catch more than it needs. As we have recently seen, an updated version of Log4j (2.15) was itself a concern. Some more advanced users create their own hot fix packages to avoid waiting for upstream security responses. Temporary policy rules can be created to enforce the presence of a specific hash for a custom-built package to ensure developers have used the internally created hot fix until the organization is comfortable using the upstream public package.
Beyond just looking at the version string, a number of mitigation strategies have emerged such as using environment variables to modify the behavior of the Log4j code. A policy rule can be added that ensures these variables are in place. Combined with a temporary allow-list entry for the version of Log4j you are using, this can be a more practical solution while you work on your upgrade strategy.
Using the Anchore Enterprise policy engine for multiple pipeline stages enables a defense-in-depth approach to ensure you are catching all entry points for vulnerable content. The single point of command and control for your security rules across any component found in an SBOM allows customers to adjust as new information comes to light.
Remediating Log4Shell At Scale
Finally, chances are you are detecting Log4j in multiple applications maintained by multiple development teams. To start the fix process, Anchore Enterprise users can trigger notifications and remediation workflows based on rules that are triggered from the policy engine. Tickets can be automatically created in Jira or GitHub, sent as emails, or posted to Slack or Microsoft Teams channels. These notifications provide not only the details of the Log4j version discovered or the policy rules that were violated but also include explicit instructions on what versions should be used to resolve the issue.
From Sprint to Marathon
The extensive use of Log4j and the severity of the exploit means security professionals and development teams are going to be dealing with the issue for many months to come. Getting immediate visibility into your risk using open source tools is the fastest way to get going. But as we get ready for the long haul, prepare for the next inevitable critical issue that surfaces. Perhaps you’ve already found some as you’ve addressed Log4j. Anchore Enterprise can get you ready for a quick and full assessment of the impact, immediate controls to prevent vulnerable versions from moving further toward production, and streamlined remediation processes. Please contact us if you want to know how we can help you get started on your SBOM journey.
