GitHub Action

Setting up the Bridgecrew GitHub Action

You can leverage GitHub actions to run automated scans for every build or specific builds, such as the ones that merge into the master branch. This action can alert on misconfigurations, or you can set it up to block code from being merged if certain policies are violated. It can also send the results to Bridgecrew for further review and remediation steps.

Typically, you wouldn’t do more than one scan during a build, such as two Actions, a CI/CD integration and a Terraform Cloud scan, so you can remove the Actions when you set up the Terraform Cloud scan or leave it for illustrative purposes.

Start with the GitHub Actions integration page within the Bridgecrew platform. Give your key a name like gh_action and select “Create.” Copy that API token for the next step in the process and click “Next” and “Done.”

GitHub Action Integration in Bridgecrew

The wizard provides example code to enable Bridgecrew as a GitHub Action.

You need to add the Bridgecrew API key you just generated to GitHub in their secrets store as an environment variable. This prevents your API key from being public when you have your code in a public repository.

Go to your fork of TerraGoat on GitHub and select “Settings”.

GitHub settings

Then select “Secrets” from the left, and click “New Repository Secret”.

GitHub Action secrets

Name the secret BC_API_KEY as instructed in the Bridgecrew integration details above.

Copy and paste your API Token from the Bridgecrew integration wizard into the value field.

Add the Bridgecrew secret

Selecting “Add secret” will list the secret in the “Settings” -> “Secrets” page.

Adding the automated workflow

Github Actions are defined as workflow files within your code repository under the .github/workflows directory. To create an action, you’ll add a new file to this directory. If you already have workflows and are familiar with the workflow file format, you could add the Bridgecrew step section to your own workflows for the same results.

To create a new workflow, select “Actions” within your TerraGoat forked repository, click on “I understand my workflows, go ahead and enable them,” then select “New Workflow.”

GitHub Action menu

Select “Set up a workflow yourself” to create a new, blank workflow.

Name the new file bridgecrew.yaml and replace the entire contents with the workflow template provided below. This takes the jobs section provided by the Bridgecrew integration instructions and wraps it in a fully functional GitHub Actions definition.

name: Bridgecrew
      - master
    runs-on: ubuntu-latest
        python-version: [3.8]
    - uses: actions/checkout@v2
    - name: Run Bridgecrew 
      id: Bridgecrew
      uses: bridgecrewio/bridgecrew-action@master
        api-key: ${{ secrets.BC_API_KEY }}
        directory: terraform/

Select “Start commit” once you’ve added the workflow file contents:

Add the Bridgecrew Action yaml

Finally, save the new workflow file into your code repository by selecting “Commit new file”.

Commit the file

The GitHub Action will start running Bridgecrew scans against the latest commit in your TerraGoat repository. You can see this by selecting the “Actions” page within your TerraGoat forked repository in GitHub. You will see a new workflow, titled Bridgecrew, and that the job that was kicked off by merging in the workflow yaml file.

Results of the Action

Selecting this job will allow you to view the status and logging output from the pipeline, where checkov will run and output any violations found in the TerraGoat codebase.

Rather than digging through the job logs, the action also outputs annotations for each violation found into the “Summary” page of the action. Again, we can see the identified misconfigurations:

Reults of the Action

The Bridgecrew GitHub Action can either pass all builds or block builds based on policy violations. The first acts as just an observability and alerting tool, the second as guardrails for developers to prevent misconfigured templates from making it into the repository. You can change this to not fail a build by adding soft_fail: true setting in the with block.