What is SAST? All About Static Application Security Testing tools

SAST is an application security technology that finds security problems in the code of applications, by looking at the application source code statically as opposed to running the application. SAST is one of the three different approaches that Application Security Testing (AST) follows, the other two being DAST and IAST.

As a summary, SAST was one of the first assisted vulnerability assessment tools. Even though it is a mature technology that enjoys high market penetration and they are relatively easy to implement, SAST tools suffer from serious problems emanating from the static analysis technology such as false positives, lack of coverage for many security risks, long waits that impede DevSecOps practices, lack of third party code coverage, and no support for Production stages. Due to these critical limitations, static analysis tools are being replaced by the IAST approach, a more modern approach.

To set the stage before going deeper into Static Application Security Testing, the overall goal of the AST family of application security technologies is to make applications more secure by reducing the number of security vulnerabilities that can be exploited by attackers. Web application security vulnerabilities come in two types; on one hand, security bugs that follow a recognizable pattern, and the vulnerability assessment can be automated. And on the other hand, business logic flaws, which can be considered design flaws and do not follow a detectable code pattern. AST tools in general, and SAST in particular, are only able to find reliably security bugs. That is why normally a pentest is recommended to complement any AST tool.

In this post, we will review the overall SAST category of application security tools including its pros and cons, and practical advice on how to evaluate a SAST tool. In a similar post, we have reviewed the IAST approach to vulnerability assessment.

Table of contents

What is SAST
Strengths and Weaknesses of SAST tools
Checklist: How to evaluate a SAST tool
How to incorporate a SAST tool
SAST compared to DAST & IAST

What is SAST

SAST (Static application security testing) also known as static code analyzers and source code analysis tools are application security tools that detect security vulnerabilities within the source code of applications. The output of a SAST is a list of security vulnerabilities, that includes the type of vulnerability and the location in the codebase of the application.

SAST technology typically involves finding specific patterns in the code that suggest suspicious code, without running the applications. Some of the vendors use regular expressions, and others build a logic graph representing the code architecture and its relations.

Regardless of the approach, the limitation of seeing the code statically is very important, because complex applications with multiple layers will behave differently in runtime depending on the conditions and input data.

Because static code analyzer tools look at the code of the application, the SAST must be compatible with the programming language of the application.

Since static code analyzer tools are closely related to the source code of the applications, they are used mainly by developers during the development stage. Depending on the maturity level of the team, static analysis can be also part of the QA and acceptance stages, but due to the large ratio of false positives, the solution must have been finely tuned prior to being applicable in this stage.

Lastly, static code analysis is not applicable to the Production stage.

Strengths and Weaknesses of SAST tools

For a long time, SAST tools were one of the few assisted approaches to find security bugs. However, as the development industry has evolved, the SAST technology has not advanced enough with it. Let’s look at the pros and cons of SAST tools.

SAST Strengths

One of the key strengths of SAST tools is the broad coverage of programming languages and development platforms. Since the complexity barriers to build a basic SAST tool are low, and the static approach is considered mature, virtually all mainstream languages have multiple vendors offering static code analysis.

Another pro is that static analysis is easy to implement and adopt. As we describe in the next section, it is fairly straightforward to add a static scanner to a development pipeline and/or to an IDE.

Lastly, developers benefit from static code analyzes, since the analysis is performed from a static source code point of view. This includes feedback on the exact location of the potential security issue.

SAST Weaknesses

The main weakness of the static analysis approach is the prevalence of false positives. Due to the limitations of the static approach, static analysis tools deliver as much as 50% of false positives, according to public data by the OWASP foundation, by means of the OWASP Benchmark project. False positives represent a tremendous waste of time as teams need to triage and validate manually each individual security bug candidate to make sure it is not a false positive.

Partially to solve the false positives problem, most code analyzers must be tuned and configured to the coding standards of the team, which requires time and is error-prone.

Lack of third-party component analysis is a serious weakness. As SAST tools require visibility of the actual source code of the application, there is no visibility of the security of those components with no source code available. This includes components outsourced to software factories, legacy libraries, and frequently, open-source projects. As much as 80/85% of the code of a modern application is third-party, which represents a serious coverage hole.

Imperfect security coverage is another limitation of static source analysis tools. Most of the modern risks involve complex sequences of actions that can only be observed when the application is running. Just looking at the source code does not provide enough information to find these serious vulnerabilities, such as insecure deserialization.

Another con is that the scanning process takes time and this slows down the development process. The security analysis of complex applications requires many hours of scanning. As a result, sometimes teams schedule the scans to run offline (such as during nights), but this practice breaks the agile philosophy.

Due to the “scan” approach described above, the results are quickly outdated. As soon as the application code changes, the security scan must be repeated. This does not scale well to teams that push frequent changes, and in general, to agile methodologies such as DevSecOps (also known as SecDevOps).

Lastly, SAST tools are not applicable to the production stage and in general, to later stages of the SDLC such as the production stage.

Checklist: How to evaluate a SAST tool

SAST is a mature security technology and there are more modern versions available, such as Interactive Application Security Testing. However, some use cases still justify the presence of a SAST in your security pipeline.

Here is a brief checklist for teams that are evaluating static code analyzers:

• Does it support our programming language(s)?
• How is the vulnerability assessment accuracy, both the detection level and false positive rate?
• Does it fit nicely with our DevOps pipeline? Is it easy to automate? Can it run from the command line?
• How well does it work with our issue tracker? Does it offer 2-way integration and customizations?
• How easy is it to consume the output of the security analysis? How flexible is the reporting?
• How flexible is the product licensing? is it based on code lines, developer seats, scans, etc?
• Are there any requirements regarding on-premise deployment versus cloud-based remote scans?

How to incorporate a SAST tool

Each organization will have different security needs. Once the compatibility is ensured by, for instance, going through the checklist listed just above, the team should draft a personalized plan to incorporate a code analysis tool into its pipeline. 

Here are some basic adoption guidelines that apply to most organizations:

People – who should use a SAST?

Depending on the maturity level of the team, the number and types of users will vary, but in general, developers should come first, and then QA and CI/CD teams. When the organization has security specialists, such as AppSec engineers and DevSecOps experts, they usually customize and tune the SAST to accommodate the organization’s security policies and requirements. Likewise, team leaders can review the high-level findings to evaluate the security position of the applications.

Since false positives will occur, most users will have to receive training regarding security practices, so they can perform the necessary false positive triage. 

Process – when to conduct static analysis?

At a minimum, the static analysis should be run when code is committed to the repository, and prior to a new release, always allowing time to filter false positives and implement the corrections.

In case the usage of the tool is metered (such as when the licensing is based on the number of scans, which is quite frequent) the team should consider the budgetary elements and plan the scans accordingly.

Technology – deployment of a SAST tool

Different vendors have different strategies to deploy their static analysis tools. In general, there are two main deployment scenarios: on-premise, when the software runs on equipment managed by the end-user; and cloud or SaaS, when the software is run and managed by the vendor.

Once installed, it is important to incorporate the tool into the larger team ecosystem: task management, code repositories, CI/CD pipeline, etc. This step should involve adding automation so that the scans occur as planned.

SAST compared to DAST & IAST

Static code analysis is one of the three main vulnerability assessment solutions, along with dynamic application security testing (DAST) and interactive testing (IAST).

The main difference between the static approach, and dynamic / interactive approach is that SAST does not require deploying and running the application. This makes it easier to automate since there is no need to deploy the application to a server.

In terms of vulnerability assessment philosophy, a SAST performs a “white box” analysis, because it can see the inside of the application, compared to a “black box” analysis in the case of DAST, and a hybrid or “grey box” analysis in the case of IAST.

Regarding risk coverage, SAST technology, generally speaking, finds more types of risks than DAST, but the modern IAST approach finds the most risks. The OWASP Benchmark finds that the best SAST tools find around 80% of the issues in the code, compared to around 20% in a web scanner. The best IAST tools find 100% of the issues, due to its modern interactive approach.

The static approach is much more prone to false positives. Since a DAST has more direct evidence of the presence of a security bug, the false positive rate is greatly reduced compared to a SAST. And since the IAST approach benefits from both static and dynamic visibility, the rate of false positives is almost zero.

As discussed above, in terms of SDLC stages, a SAST is normally useful during development, and to some extent during QA, compared to web scanners which come into play at opposite times since DAST is mostly useful during QA, and especially, for production systems. The IAST vulnerability assessment technology is applicable to all stages of the development cycle.

For a more detailed view of how static analysis compares against DAST and IAST, read this post.