CloudNative.Quest

Quest to Cloud Native Computing

Using GitHub actions for detecting Log4J vulnerability in containers

Author:


Modified: Thu, 2021-Dec-30

Introduction

Log4J is a Java library used for creating log in a Java application. Recently, a vulnerability was found for log4j version >= v2 and less than v2.14.1. The vulnerability should be completely fixed in version 2.17.1. (Always check the latest update because the Log4Shell vulnerability has multiple security updates a in short period of time.) This vulnerability is in the headlines of many security or IT related websites. It is because the vulnerability is a RCE (Remote code execution), it would affect lots of IT infrastructure. Always check the newest security announcement and recommendation like Log4J offical site, it is found that the first patch (version 2.15.0) for this vulnerability is not complete.

In the last article, we have come across several tools for scanning containers. How about scanning containers with GitHub actions? We could look at some GitHub actions for scanning containers.

Setup the vulnerable container

First, we have a GitHub repository with:

  • Dockerfile

  • The vulnerable Log4J Java Library (v2.14.1)

  • GitHub actions for building container

  • GitHub actions for scanning container

The Dockerfile is simple, it just copies the vulnerable library into the container:

        FROM docker.io/debian:buster-20201209

RUN mkdir /data

COPY log4j-core-2.14.1.jar /data

Here, we use an old version of Debian as the base OS. I wanted to see how the tools are reporting the security vulnerabilities. I also copy the vulnerable Log4J library into the container.

GitHub actions for scanning containers

The official documentation for GitHub code scanning is in here. In short, just go to the Security tab of the GitHub repository, then in "Code scanning alerts", then click the "Setup code scanning button".

setup code scanning

The Web UI would present several workflows for security scanning. For the purpose of this article, we choose these two open source workflows: Trivy and Anchore container scan.

After selecting the workflow, the GitHub Web UI would present the demo workflow template that you can use. Usually you just need to fill in information like the location of the Docker container and is ready to go.

Example:

              - name: Run Trivy vulnerability scanner
        uses: aquasecurity/trivy-action@2a2157eb22c08c9a1fac99263430307b8d1bc7a2
        with:
          image-ref: 'docker.io/my-organization/my-app:${{ github.sha }}'
          format: 'template'
          template: '@/contrib/sarif.tpl'
          output: 'trivy-results.sarif'
          severity: 'CRITICAL,HIGH'

      - name: Upload Trivy scan results to GitHub Security tab
        uses: github/codeql-action/upload-sarif@v1
        with:
          sarif_file: 'trivy-results.sarif'

By using the GitHub actions, we do not need to manually install the scanning applications. We just configure which container to scan (image-ref) in the first step of the workflow. The GitHub actions would install the Trivy automatically and scan the container. The result would be written to a SARIF file. As a side note, SARIF is called Static Analysis Results Interchange Format. It is the industry file format standard for static analysis tools. See this article for details.

In the second step of the workflow, the SARIF file would be uploaded to GitHub. You can view the result in the "Security Tab" of your repository. Click the "view alerts" button.

view alerts

We then input "log4j" as the filter. Now, Trivy and Anchore show there is Log4J security vulnerability:

code scanning result

Take Anchore as example, it would record the path of the file that has vulnerabilities, the current version and the fixed version of the library.

result anchore

Conclusion

In my testing, I found Trivy, Anchore, Sysdig GitHub actions and Snyk could detect the Log4J vulnerability and logged it in the Code Scanning alerts section of GitHub.

Besides GitHub actions, you may want to check out WhiteSource Bolt. It is free for open source projects. It could detect the Log4J vulnerability in the source code repository. It would create issues if vulnerabilities were found.


Share this article


Related articles



Twitter responses: 1


Comments

No. of comments: 0

This site uses Akismet and Google Perspective API to reduce spam and abuses.
Please read and agree the privacy policy before using the comment system.