Using Grype to Identify GitHub Action Vulnerabilities

Using Grype to Identify GitHub Action Vulnerabilities

About a month ago, GitHub announced the presence of a moderate security vulnerability in the GitHub Actions runner that can allow environment variables and path injection in workflows that log untrusted data to STDOUT. You can read the disclosure here for more details. Given at Anchore, we build and maintain a GitHub Action of our own; this particular announcement was one we were made aware of. While I’m sure many folks have taken the time to update their GitHub Actions accordingly, I thought this would be a good opportunity to take a closer look at setting up a CI workflow as if I were developing my own GitHub Action, and step through the options in Anchore for identifying this particular vulnerability.

To start with, I created an example repository in GitHub, demonstrating a very basic hello-world GitHub Action and workflow configuration. The configuration below scans the current directory of the project I am working on with the Anchore Container Scan Action. Under the hood, the tool scanning this directory is called Grype, an open-source project we built here at Anchore.

name: Scan current directory CI
on: [push]
jobs:
  anchore_job:
    runs-on: ubuntu-latest
    name: Anchore scan directory
    steps:
    - name: Checkout
      uses: actions/[email protected]
    - name: Scan current project
      id: scan
      uses: anchore/[email protected]
      with:
        path: "./"
        fail-build: true
        acs-report-enable: true
    - name: upload Anchore scan SARIF report
      uses: github/codeql-action/[email protected]
      with:
        sarif_file: ${{ steps.scan.outputs.sarif }}

On push, I can navigate to the Actions tab and find the latest build. 

Build Output

The build output above shows a build failure due to vulnerabilities identified in the project of severity level medium or higher. To find out more information about these specific issues, I can jump over to the Security tab.

All CVEs open

Once here, we can click on the vulnerability linked to the disclosure discussed above. 

Open CVE

We can see the GHSA, and make the necessary updates to the @actions/core dependency we are using. While this is just a basic example, it paints a clear picture that adding security scans to CI workflows doesn’t have to be complicated. With the proper tools, it becomes quite simple to obtain actionable information about the software you’re building. 

If we wanted to take this a step further “left” in the software development lifecycle (SDLC), I could install Grype for Visual Studio Code, an extension for discovering project vulnerabilities while working locally in VS Code. 

Grype vscode

Here we can see for the same hello-world GitHub Action, I can get visibility into vulnerabilities as I’m working locally on my workstation and can resolve these issues before I end up pushing to my source code repository. I’ve also just added two places for security checks in the development lifecycle in just a few minutes, which means I am spreading out my checks, providing more places to catch myself should I create issues. 

Just for good measure, once I update my dependencies and push to GitHub, my CI job is now successfully passing the Anchore scan, and the security issues that were opened have now been closed and resolved. 

All CVEs closed

CVE closed

While this was just a simple demonstration of what is possible, at Anchore, we generally just think of these types of checks as good hygiene, and the more spots in the development workflow we can provide developers with security information about the code they’re writing, the better positioned they’ll be to promote shared security principles across their organization and build high-quality, secure software.