Anchore and GitHub Actions, A Tutorial

In this blog we're going to show you how, with very little code, you can add robust security scanning, alerting and reporting to your existing GitHub projects.

(If you don’t get why, check out our GitHub Actions intro blog for some more background).

First, go into your Github repository and find the Action tab; it should be about midway along, as shown in the screenshot below:

If you've not set up any actions in this repo before, you'll be greeted by the default setup screen.

We're going to skip this by selecting the option on the left-hand side titled, 'set up this workflow yourself'. This link takes us to the Action editor. You'll find it has some example code already in place. So, go ahead and replace it with the following workflow:

name: Anchore Scan
on: [push]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v1
    - name: Docker Build
      run: docker build . --file Dockerfile --tag testrepo/testimage:latest
    - uses: anchore/scan-action@v1
      with:
        image-reference: "testrepo/testimage:latest"
        dockerfile-path: "./Dockerfile"
        fail-build: true

If you are unfamiliar with Github Action syntax, you can find an excellent guide here.

In this workflow, we are creating a job called 'Anchore Scan', and setting it to scan every time that code is pushed into the repository. In addition, we are checking out our source code into an Ubuntu container and building a container based on a Dockerfile found in the root of the project.

Once the container is built, we then utilize Anchore Engine by calling the anchore/scan-action integration. As you can see, the scan-action takes three parameters:

First, image-reference, refers to the tag of the Docker image we created in the previous step.

Next, the dockerfile-path, highlights the Dockerfile, within the source code that is used to build it.

Finally, we have the fail-build. This option marks the action as failed if Anchore Engine finds anything in breach of its default policy.

This workflow is already looking pretty good, but we're going to take it a step further and post a Slack alert for failures, offering us interactive feedback on security issues.

For the next step, you'll need a slack incoming webhook.

Once you have the webhook, add it as a secret to your Github repository by going into Settings and then Secrets in your repository settings. Name the secret SLACK_WEBHOOK, and then add the following code to the workflow:

  - name: Send alert
      if: failure()
      uses: rtCamp/[email protected]
      env:
        SLACK_CHANNEL: general
        SLACK_COLOR: '#3278BD'
        SLACK_ICON: https://github.com/rtCamp.png?size=48
        SLACK_MESSAGE: 'Post Content :rocket:'
        SLACK_TITLE: Post Title
        SLACK_USERNAME: rtCamp
        SLACK_WEBHOOK: ${{ secrets.SLACK_WEBHOOK }}

This code uses another custom action to send messages to slack. Note the if: failure() directive; this ensures that the message is only sent if our Anchore scan failed, which in most cases means it found a security issue (because, although we’re lovely people, you only really want to hear from us if there is a problem).

Last up, we're going to add a final action to our workflow to collect the detailed reports that Anchore Engine provides when scanning a container. These reports contain relevant data such as the bill of materials, any CVEs found and detailed build logs (maybe you can think of a security-focused colleague who finds this sort of stuff compelling).

Add the following code to your workflow:

 - name: Upload artifact
      uses: actions/[email protected]
      with:
        name: AnchoreReports
        path: ./anchore-reports/

This code makes use of the upload-artifact Action. It takes the contents of the anchore-reports directory created by Anchore, zips it, and makes it available as a build artifact.

Now we're ready to add our workflow. Click the 'start commit' button on the right-hand side, and commit the action to our repository. Since this is a code push into the repository, it triggers the workflow we've just created. Click on the actions tab in your repository to be taken to a list of workflows. On the left, you should see our workflow, and if you click on it, you'll see the current output for the running job. Once it's finished you should see output similar to the screenshot below:

If you examine the details of the `runanchore/scan` step inside the build log, you should see something similar to the following screenshot:

We've got a few warnings, but otherwise, we're in good shape. Finally, clicking on the Artifacts tab on the top right-hand side downloads the Anchore Engine reports. This gives us an amazing depth of knowledge on the image we scanned.

With Github Actions, a few lines of YAML and Anchore Engine, you can embed container scanning into the developer workflow, pushing this increasingly crucial security practice left and into the hands of developers. This immediate and easy feedback helps you keep your projects and data secure, without an enormous overhead.

To check out the full documentation for Anchore Github Actions and take a more detailed look at additional functionality such as custom policies visit the GitHub page.

As always, we'd love to hear your feedback, and we hope you love using Anchore in Github as much as we do.