Static Application Security Testing (SAST)

What if you could take multiple senior developers and security experts, distill them into a tool, and then have the ability to run that tool against your code every single time you make changes, and way before they get to production?

Well you can, but a surprising number of people are not taking advantage of this.

In 2020, GitLab surveyed five thousand IT professionals across different industries and company sizes, and found that 60% of developers didn’t run any sort of static code testing, at all. Fast forward to 2022, and that number is now only 47%.

So that’s a big change in a very short period of time!

But is that really a good thing, and is static code testing that important anyway, or is it just yet another type of security tool that’s over-promising and under-delivering?

Let’s take a look in this episode of Explained in 180 seconds.

Prefer watching instead of reading? Here you go:

What is Static Application Security Testing (SAST)?

Static code analysis, also known as Static Application Security Testing, or SAST for short, is security testing that looks at code, from top to bottom, or in pieces and components for security vulnerabilities.

It doesn’t require a working application: you don’t have to compile it or run it in order to run the tests, which means you can do it super early in the development lifecycle which is the best time to find bugs.

Running open-source SAST tooling

Let’s see how this actually works in practice by running a SAST tool and looking at its results. There are many types of SAST tools out there, but in this article we’ll use a tool named Bearer. Bearer sponsored the YouTube video but they are not sponsoring this post. They created an open-source SAST tool that you can use for free, so you can follow along if you’d like, and you can also star the repo to bookmark it.

There are a few ways you can install Bearer, but for this, I’ll just use the first method which is the fastest way:

curl -sfL https://raw.githubusercontent.com/Bearer/bearer/main/contrib/install.sh | sh
Code language: JavaScript (javascript)

Bearer can support multiple languages and frameworks, including Ruby. A sample application we can use is RailsGoat which is a Ruby on Rails app that’s purposefully vulnerable. You could also use the OWASP Juice Shop or really any codebase you’d like.

We can clone the codebase with this command:

git clone https://github.com/OWASP/railsgoat
Code language: PHP (php)

and right after that we can run a bearer scan:

./bin/bearer scan railsgoat

(You may have to access bearer differently than ./bin/bearer depending on your installation method and system. Comment below if you need help!)

By default, bearer runs a SAST scan, but you can also have it run a secrets scan:

./bin/bearer scan . --scanner=secrets

Which will look for any hard-coded secrets that are in the code.

Or you can run a privacy scan, which will provide useful information about how the codebase uses sensitive data.

The SAST Results

After the SAST scan is complete, you get a detailed report of anything that was found, which looks like this:

What sorts of issues can SAST find?

SAST tools can find all sorts of vulnerabilities or issues like:

• Non-filtered user input (which can lead to sql injection, path traversal, etc.)
• Leakage of sensitive data through cookies, internal loggers, and so on…
• Weak encryption implementations
• Unencrypted communications of sensitive data
• Or even hard-coded secrets and tokens

And it can look for those issues every time you make changes to your codebase.

How/when can you use SAST?

This is the magic of SAST scans, because we can use them early and regularly in our development lifecycle. In fact, we can run scans a few different ways depending on your codebase and your organization’s requirements, like:

• In the IDE you’re already using (such as VSCode)
• As part of your CI pipeline to verify code changes (ie: with GitHub Actions)
• Or on a schedule for full codebase scans (like during the night when no one is working)

So should you use SAST?

So at the beginning of the article when I asked: “is this large increase in SAST tooling adoption really a good thing?”

The short answer is: absolutely yes! Most organizations should but running SAST

The longer answer is that SAST, just like any other security tool, shouldn’t replace learning about application security and continuously trying to write better code — especially because it will never catch every single vulnerability that exists…

…but it can still be a big help by catching common mistakes that might otherwise slip through.

If you enjoyed this post, check out our Explained playlist and subscribe for more content like this. Also, now that we’ve seen SAST used in action, with 47% not using static code analysis, how does that make you feel about the software you use and run every single day? Personally makes me feel kinda weird…

Let me know in the comments below what you think!

Thanks for reading, and see you next time.