Using GitHub’s security features to help identify Log4j exposure in your codebase

The world is reacting to the news that a popular Java library, Apache Log4j, contains a vulnerability in versions prior to 2.16.0. When exploited, that vulnerability can result in attackers being able to remotely execute code on the victim’s system. GitHub’s security team recently shared how we’ve responded to this issue on GitHub.com, GitHub Enterprise Cloud, and GitHub Enterprise Server. In this blog post, we’ll tell you more about how you can use GitHub’s security features to help assess and address your exposure.

The fix

Currently, the best-known solution to mitigate any exposure from this vulnerability is to upgrade to Log4j version 2.16.0 in your application. If you’re unable to update to version 2.16.0, we recommend mitigating by ensuring the -Dlog4j2.formatMsgNoLookups=true system property is set on both client- and server-side components of your application.

Assessing and reducing exposure using GitHub Dependabot

If you’re a GitHub user and are using Maven to manage your Java dependencies, you can use GitHub Dependabot to surface all locations Log4j is explicitly declared as a dependency. To enable Dependabot, see the documentation linked at the bottom of this post. Once enabled, you will receive alerts and pull requests to upgrade to the patched Log4j version. GitHub has sent over 175,000 alerts and pull requests for this vulnerability already.

After enabling Dependabot, you can view an organization or server-wide list of alerts for the Log4j vulnerability using the Advisory Database:

• <https://github.com/advisories/GHSA-jfh8-c2jp-5v3q/dependabot&gt;
• https://<your-github-enterprise-server>/advisories/GHSA-jfh8-c2jp-5v3q/dependabot

If you use Gradle or another mechanism to manage your Java dependencies, Dependabot will not alert for those repositories. GitHub is continuously working to add enhancements, including Gradle support to Dependabot alerts, to see more details visit our public roadmap.

Assessing and reducing exposure using GitHub code scanning

If you’re a GitHub Advanced Security customer or if you maintain a public open source project, we’ve developed an experimental CodeQL query that you can run to identify potentially affected lines of code in your GitHub repositories. The query will detect situations in which untrusted user data flows into Log4j logging statements. If a codebase depends on a vulnerable Log4j version, any alerts generated by this query almost certainly indicate a security risk.

You can run the CodeQL query by using the CodeQL CLI, or you can enable the query in GitHub code scanning by configuring a custom query using the queries directive in your CodeQL workflow configuration:

Summary

As the industry works quickly to assess exposure and patch, GitHub recommends for users to enable Dependabot as part of their overall response. While this will not provide a complete picture of exposure, it will very quickly identify explicit dependencies that can be patched rapidly. For GitHub Advanced Security users, the provided experimental CodeQL query can also help.

If you need help to enable Dependabot or GitHub code scanning along with CodeQL, please refer to the documentation below or talk to one of our security specialists for further advice or a GitHub Advanced Security Demo.

• Enabling Dependabot for Cloud
• Enabling Dependabot for Server
• Dependency Graphs and Insights
• Upgrading GHES with a hot patch