Crush Github Action

Everyone is talking about pushing left. I feel like I’ve been talking about Agile Security since like 2010. Whatever we’re going to call it, the idea is that we want to be able to do our work earlier in the development process where developers can touch and feel it.

Its not all about tools

Although I’m going to show how to do a neat little tool integration, I want to re-iterate that application security is only a little bit about tools.

The green compliance checkbox you get with tools is never real. – Me. 🙂

By all means, use tools.

But pushing left also includes:

• Writing explicit security requirements
• Doing security testing with dev frameworks
• Security Code Review / Security Architecture Review
• Tracking architecture
• Applying infrastructure as code and security to that

Remember Crush

Crush (Sort of short for code review helps us) is a simple tool we built to help us when we’re doing code review. To make it simple, we search for strings that are often associated with significant errors. We offered a deeper intro in this blog post about why we wrote crush or the README.

Will Butler wrote a great blog post about how to find vulnerabilities in code. We integrated all of his “bad words” into Crush
in the most recent update. Some were already there. You can run Crush to find them like this:

docker run -v ldir:/tmp/target jemurai/crush:0.6.1 examine --directory /tmp/target --tag badwords --threshold 1

Where ldir is a local directory that Docker can see (on a Mac, this is easy if it is under your user, eg. /Users/<you>/directory). It will be noisy. I think Will is onto some good stuff with the badwords but initial testing with this suggests it might be too much to be useful and could require further tuning. That is why we set the threshold to 1 for most of these checks. Any easy way to make it work the way you want would be to up the thresholds on the things you really want to check, then only check above that threshold.

The way we use Crush is to quickly make sure we didn’t miss anything obvious during a code review. Its like a code review assist. We might see everything anyway, but this just makes sure we don’t miss anything we should catch.

Crush is open source, written in Golang and generally fast enough to use in a git precommit, CI/CD or almost any process.

GitHub Actions

I got really excited about GitHub actions with ZAP’s blog post about using ZAP.

It turns out it is very easy to package anything that can run as a Docker container as a GitHub Action. Here is the code we use in Crush:

name: 'Jemurai Crush'
description: 'Crush code - automate code review'
branding:
  icon: 'code'
  color: 'red'
inputs:
  dir:
    description: 'The directory to scan'
    required: true
    default: '.'
runs:
  using: 'docker'
  image: 'Dockerfile'
  args:
    - 'examine'
    - '--debug'
    - 'true'
    - '--directory'
    - ${{ inputs.dir }}

Simply by putting this in our root directory in a file called action.yml, and then releasing it, we can make our action available.  In this case, our tool can be run like this:

docker run -v <local-dir>:/tmp/target jemurai/crush examine --debug true --directory /tmp/target.

Using the Action

Using the action is super easy - just drop a file describing the action you want to to this directory: .github/workflows/crush.yml.

# This is a basic workflow to help you get started with Actions
name: CRUSH

# Controls when the action will run. Triggers the workflow on push or pull request
# events but only for the master branch
on:
  push:
    branches: [ master ]
#  schedule:
    # Runs every day At 01:00.
    #   - cron:  '0 1 * * *'
jobs:
  crush_job:
    runs-on: ubuntu-latest
    name: Assisted code review
    steps:
      - name: Checkout
        uses: actions/checkout@v2
        with:
          ref: master
      - name: Crush Scan
        uses: jemurai/crush@v0.6.1
        with:
          dir: .

That’s it! Now we’re cooking with gas, as … someone used to say.

Now, we’re still working on better integrations where we can make Crush create a better report or automatically log GitHub issues. But the basic idea is so easy and clear that it would be silly not to start playing with these types of automations now!