Types of Testing You Should Care About: Static Application Security Testing

Static Application Security Testing (SAST) is one of the most complex types of test for your application, but also one of the simplest to implement. SAST tooling examines your source code looking for security weaknesses. It will report on those weaknesses and suggest improvements.

The purpose of this type of test is to find and prevent you from integrating potentially risky code.

Think of it a bit like a linter focussed on security issues.

By its very nature, the tooling needs to know about your programming language and potentially the web framework that you're using. Different types of vulnerabilities exist in different types of applications and SAST tooling is generally aware of that. While there are some tools that can do broader analysis, most focus on language-specific bugs and a common set of vulnerabilities (like the OWASP Top 10).

When only looking at open source options there are both language specific tools (i.e. SpotBugs, Bandit) and more broad tools that support scanning multiple languages (i.e. semgrep, Sonarqube, Bearer, Horusec) available. There's really no reason why you can't use multiple scanners. They will mostly be checking for the same things, but pairing bandit for your Python code, then semgrep to scan both your Python and Terraform code within your repository is a valid choice.

The OWASP project maintains a list of both open source and commercial SAST tooling.

You should set up these checks to run locally on developer machines before code is pushed to your source repository using a pre-commit hook. This reduces the risk of code problems like hard-coded secrets sneaking into your repository.

Once you have your tooling running locally, set up the SAST checks in your CI/CD pipeline. This should help to stop potential security issues from being merged into your main branch. Include the configuration of the tooling in your repository to ensure consistency between local and CI runs.

Here's an example of a GitHub Actions workflow that runs bandit on a Python project using a local configuration file from my open source Python CI post:

bandit:
  runs-on: ubuntu-latest

  steps:
    - uses: actions/checkout@v3

    - name: Set up Python
      uses: actions/setup-python@v4
      with:
        python-version: 3

    - name: Install bandit
      run: |
        python -m pip install bandit[toml]

    - name: Run bandit scan
      run: |
        bandit -c pyproject.toml -r .

It's important to note that SAST tools aren't set and forget. Test definitions can be updated regularly. It's a good idea to have a regularly scheduled CI run that checks your code with the latest versions of your SAST tools. Old code may have problems that will be detected by new check definitions. With GitHub Actions this is a simple as adding a cron: directive in the on: block.

SAST tooling doesn't protect you from every possible security issue, and it doesn't remove the need to peer-review. What it does provide is a very solid first line of defence for the security of your web application. Adding it is simple, so there's really no reason not to.