The implications of adding SAST to your CI/CD pipeline

DevSecOps is all about better integrating security into the software development life cycle (SDLC). When combined with the desire to automate repetitive tasks, the inevitable conclusion is to put any repeatable testing tool into your app’s build pipeline. For any tooling that involves code analysis, it makes sense to sync up with existing testing workflows. That’s where CI comes in. This article looks at why you should add a SAST tool to your CI/CD workflow, as well as why you’ll want to carefully assess the impact doing so will have on your team.

What are static application security testing (SAST) tools?

Static application security testing (SAST) is a type of security testing that analyzes your source code. Tools in this category check for security vulnerabilities, coding errors, and missing best practices to lower the security risks associated with your codebase.

SAST tools aim to integrate into the SDLC as early as possible. This lets them notify developers of vulnerabilities before the code goes live. Each tool is different, but they all work on a set of pre-defined rules to check for security vulnerabilities, such as:

• Cross-site scripting (XSS)
• SQL injection
• Access control misconfigurations
• Insecure design patterns
• Improper use of cryptography
• And many more.

It’s important to remember that this happens at the code level. This is both an advantage and disadvantage of SAST tools. They don’t add additional bloat or risks by running inside or alongside your application in production, but they also can’t watch for attacks of vulnerabilities that occur live. 

Instead, they are run manually, or ideally as part of a continuous integration or continuous deployment (CI/CD) pipeline.

How does CI/CD work?

Continuous integration and continuous delivery/deployment (CI/CD) are slightly different, but often paired workflows. They act as the step between your code and the production environment. CI/CD pipelines may include steps like unit testing, integration testing, linting, building your application, sending out notifications, and finally deploying or delivering your application. 

The goal of CI/CD is to trigger these automated processes whenever code changes. This could be on every commit, but it is often tied to a successful pull request or release.

All the big version control providers, like GitHub and GitLab, offer CI/CD workflows natively. In addition, you can use a service like CircleCI if you want to keep the two separate. 

The advantages of adding SAST to CI/CD

Stop sending secure code to production. That’s the big one. Here are some additional advantages.

• Early detection. SAST scans don’t need a running app, so you can have them run whenever code changes—even if the app isn’t live or ready to be live yet. This allows developers on your team to fix problems before opening a PR. And more importantly, before pushing to production.
• Improved code quality. The phrase “code quality” means something a little different to every team, but what I mean here is more secure code. Linters have the code smells covered, but SAST tools in your CI stop dangerous code from breaking free.
• It’s automatic. CI workflows make it so the SAST happens automatically. Set it and forget it. You don’t need to remind everyone to run the scan locally; it just happens when the rest of the tests run.

The disadvantages of adding SAST to CI/CD

I’d love to say it’s all positives, but there are some disadvantages that many SAST tools suffer from when added to CI/CD.

• False positives. Ask anyone how much they like watching tests fail. Now see what happens when a test fails for a problem that isn’t a real problem. That’s the issue with false positives. In security, it’s better to risk an extra warning than let a vulnerability slip by. For development teams, this means extra noise in their workflows.
• Limited scope. As mentioned earlier, SAST can’t protect you from anything that happens live. It’s static for a reason. Anything beyond your codebase is outside of the scope of what a SAST tool can assess.
• Scanning time. Another scan adds to the time it takes for tests to run. This can be greatly reduced with diff scanning—where scans only occur on new or changed files—but it’s one more progress spinner holding up a release.

Adding a SAST tool to your pipeline

Setting up new tooling in your CI/CD has never been easier. SAST tools, version control providers, and CI/CD providers know how important this capability is to customers, so they make it easy. Bearer CLI does just that, by offering both platform-specific and universal options.

If you’re a GitHub user, Bearer CLI has an official GitHub action. This lets you add a new job to your existing GitHub action workflow. There are also customization options in case the defaults don’t work for your use case. The basic setup looks like this:

# .github/workflows/bearer.yml
steps:
  - uses: actions/checkout@v3
  - uses: bearer/bearer-action@v2

If you’re using GitLab CI, updating the .gitlab-ci.yml file will tell GitLab to run Bearer CLI as part of the CI/CD pipeline. The setup looks like this:

# .gitlab-ci.yml
image: 
  name: bearer/bearer
  entrypoint: [ "" ]

bearer:
  script: bearer scan .

For all other CI/CD services, many tools—Bearer CLI included—offer a docker image. This is used behind the scenes by GitLab too. For any service that supports docker images, like CircleCI, you can pass the image name to the job and tell it what commands to run.

The verdict

So should you add a SAST tool like Bearer CLI to your CI/CD? Absolutely. Tools that prioritize customization and offer features that limit false positives and contextual set severity can shift the weight away from the disadvantages. With Bearer CLI you can even leverage additional outputs to generate privacy reports and dataflows in addition to the standard rule-based report. Give it a try today.