Static Application Security Testing (SAST)

Keeping your source code secure without having to think too much about it is every developer’s goal. Often developers don’t have the security background to be able to avoid insecure programming patterns and know how to use secure APIs. That’s where static application security testing (SAST) comes into play. SAST allows you to analyze your source code for security vulnerabilities so you don’t have to.

SAST is a vulnerability scanning technique that focuses on source code, bytecode, or assembly code. The scanner can run early in your CI pipeline or even as an IDE plugin while coding. SAST tools monitor your code, ensuring protection from such security issues as saving a password in clear text or sending data over an unencrypted connection.

How Does SAST work?

Here are the top 5 things to know about Static Application Security Testing (SAST):

  1. Analyzes the application from the “inside out” 
  2. Can run during all phases of the SDLC
  3. Usually requires to create a build model that the tool understands
  4. The analysis is based on a series of rules 
  5. There are multiple analysis types, each focuses on specific types of findings (see the image below)
5 sast analysis types
5 SAST Analysis Types

How Does SAST Differ from Other Security Testing Methods?

In order to help you determine whether a particular security testing method is a good fit for your application testing environment, it’s important to consider what it has to offer as well as its limitations. Let’s examine the differences between each of these testing methods.

static application security testing SAST vs DAST vs SCA

Static application security testing (SAST) focuses on code. It works early in the CI pipeline and scans source code, bytecode, or binary code in order to identify problematic coding patterns that go against best practices. SAST is programming-language dependent.

Dynamic application security testing (DAST) is a black-box testing method that scans applications in runtime. It is applied later in the CI pipeline. DAST is a good method for preventing regressions and doesn’t depend on a specific programming language.

Interactive application security testing (IAST) is similar to DAST in that it focuses on application behavior in runtime. But IAST analysis is rather based on a combination of black-box testing, scanning, and analysis of internal application flows. The benefit of IAST is its ability to link DAST-like findings to source code like SAST. The downside of this approach is that it makes IAST programming-language dependent and can only be performed later in the CI pipeline.

Software composition analysis (SCA) focuses on third-party code dependencies that are used in the application. SCA is very effective in applications that use many open-source libraries. This method is also programming language-dependent.

Read more about SAST vs DAST, what is the difference and how to combine the two of them.

How Does SAST Fit with Other Application Security Testing Methods?

SAST works on source code and scans your code lines for vulnerabilities. This is in contrast to DAST, which doesn’t know anything about the code and works only on inputs and outputs of your running application. In practice, they complement each other. A SAST tool can find vulnerabilities a DAST tool wouldn’t necessarily find, and the other way around.

But the biggest difference is speed. A DAST tool requires executing and using an application, which can take quite some time if the application is very complex. A SAST tool, on the other hand, can scan the source code and compare it to best practice rules to give you tips on how to improve it.

The idea here is that you would run a SAST tool early in your development pipeline, for example, in the IDE while coding; or at least at the start of the CI/CD pipeline on your development servers. And in a later stage, you would run a DAST tool with the compiled binary. For vulnerabilities that are found by both, you want the fast SAST tool to find it. Everything that can’t be found with the SAST tool will be left for the DAST tool later.

SAST Pros & Cons

As previously noted, SAST tools aren’t perfect; and if possible, they should be used in conjunction with a DAST tool. Let’s take a look at the pros and cons of SAST tools and what these mean in practice.

Pros:

  • Early in development: SAST works solely on source code, checking it against best practices. This means SAST can be applied when you’re actually writing your code. IDE plugins for SAST tools are common and can catch problems before anything is checked into version control.
  • Shows problematic code locations: Since SAST works on source code, it can show you the exact location of a vulnerability. This makes searching and fixing them quite efficient.
  • No test cases required: DAST tools will require you to decide what you need to test, while SAST tools will simply apply all their rules to your codebase. Often these rules are based on many different projects and years of programming experience. This allows you to catch vulnerabilities you didn’t even know existed. These rules can be manually implemented by the SAST tool creator or automatically generated via machine learning algorithms, which are learned on popular-open source repositories.
  • No execution required: SAST works on the source code before the application actually runs. SAST scans are therefore much quicker than running a whole DAST testing suite.
  • Easy automation: Scanning of text files doesn’t require any GUI interaction. This means SAST tools are much easier to automate than DAST tools, which require much more setup to run and use the application.

Cons:

  • False positives: Since SAST works on source code, it often doesn’t take the whole picture into account. As a result, SAST tools usually detect a huge number of issues when the tools check source code for the first time. Most, however, end up being false positives. SAST also finds problems in code that might be problematic in that specific line of code but are solved down the line.
  • Missing context: Unsanitized user input is one example of such a false positive. This is a huge security risk, but an unsanitized input on the frontend is often cleaned up on the backend. And it’s quite common that frontend and backend code aren’t even in the same repository, meaning the SAST tool can’t know about the sanitation, prompting the developer to fix this.
  • Language dependency: SAST has a strong code dependency. For prevalent programming languages (e.g., Java and C#), there are plenty of SAST tools available, but for more niche languages (e.g., ReScript and Nim), there are very few SAST tools out there.

3 Steps to Successfully Implement SAST

Setting up a SAST tool is quite easy when it is done right at the start of a new project. It can, however, become challenging when a project already has accumulated thousands of code lines. In the latter case, you should plan for it to take many days to get things up and running. It may also block out the schedules of some of your most skilled developers to get things right, especially checking for false positives.

1. Find the Right Tool

First, you need to find a tool that fits your development process and supports your programming language and budget. 

It is important to distinguish the difference between conventional SAST tools and developer-first SAST tools.

SAST isn’t a new concept; conventional SAST tools are sluggish and take hours or days to complete. On top of that, conventional SAST tools throw an overwhelming amount of false positives at developers, leading them to avoid these tools altogether.

Conventional SAST tools would be moved out of the CI/CD pipeline into a separate process, which further complicated and slowed down the release cycle. Another issue was their way of communicating issues to developers: often, a tool would just drop a pile of security vulnerabilities on them with no actionable advice on how to get rid of them.

Next-generation developer-first SAST tools like Snyk Code address these problems by focusing on speed. They can even integrate with your favorite IDE and notify you about security problems in your code as you’re typing it.

Depending on your workflow, a fast SAST tool can also be run when you commit or push your code repositories. Developer-first SAST tools also give you actionable notifications and insights for your security vulnerabilities to help solve problems.

2. Weed Out False Positives

Next, you need to weed out any false positives. None of your developers will take such a tool seriously if they’re overwhelmed with false alerts. Depending on the code base size, this cleaning process can take quite some time, since a skilled developer must go through all of the issues the SAST tool found to ensure they don’t pose any real threat.

Snyk Code AI engine relies on Snyk’s very own hand-curated vulnerability database, and reference commits as its training set. All of this helps to significantly reduce false positives.

3. Incorporate in Your CI Pipeline

The next step is incorporating the SAST tool in the continuous integration (CI) pipeline. As mentioned already, some tools come with IDE integration. But developers are pretty picky when it comes to their IDEs, so chances are not all IDEs are supported by the SAST tool.

Developers could also simply forget to run the tool before checking in new code. That’s why CI integration is extremely important for SAST tools. This way you can be sure no code that wasn’t checked at least once for security vulnerabilities makes its way into production.

Integrate SAST into your workflows

Find code security issues just using a CLI, in your IDE or even in a Pull Request check integration

Summary

The ability of SAST tools to catch security problems early in the development process means that even in deadline-driven environments, developers don’t need to constantly worry about following best practices.

Keep in mind, however, that depending on how late in the software development life cycle SAST is integrated, it can take a lot of effort to get it up to speed. Conventional SAST tools will yield many false positives, which developers need to weed out. And if the system is based on a niche programming language, there might not even be a SAST tool available on the market to help with your security issues. Developer-first SAST tools successfully address those issues and offer a more seamless and efficient process. Developer-first SAST offers significant benefits, making it a tool every security-conscious company should have in its toolbelt.

Don’t spend your days weeding through false positives. Ensure efficient and actionable developer efforts with Snyk Code, a developer-first SAST tool based on machine learning and offered for free for open-source repositories.

April 20, 2021
| By Liran Tal