What is SAST?

When you want to test the security of an application before you bring it into production, you either have access to the source code (this is called white-box testing), or you do not (this is called black-box testing).

Using both types of testing is preferable, but if you can only choose one, white-box testing is preferable to accurately understand what is happening, or supposed to be happening, and to detect many significant security problems that cannot be picked up during system and user acceptance tests or with black-box testing.

What are SAST tools?

SAST, which stands for Static Application Security Testing, is one of the white-box testing methods. SAST tools look at the source code or binaries of an application for coding or design flaws, which are indicative of security vulnerabilities, and even concealed malicious code.

OWASP provides a list of the main Source Code Analysis Tools. Without endorsing any of the vendors, the page presents the tools and the technologies for which they are adapted.

How do SAST tools work?

SAST tools analyze the application from the “inside out” to test areas such as control structure, security, input validation, error handling, file update, and function parameter verification. They only work before the system is implemented as they do not require the application to be deployed or running. Thus, SAST tools can run during the development phase of the SDLC: Some lightweight tools can be used at any point within the development phase and even be used as helpers for the developers while they are coding, while others are best suitable for a later stage when the code is in a stable state and can be compiled.

Implementing a SAST tool usually requires developers to create a build model that the tool understands. The build model will be used to produce a standardized model of the source code which can be interpreted by the analysis engines. The analysis is based on a series of rules which determine what should be assessed within the source code. It is critical to be aware of this rules list and to customize it to be suitable for your needs and for the application.

What are the available analyzers?

SAST tools use their engines for the following types of code analysis:

Dataflow analysis

Dataflow analysis tracks the flow of data through the application to determine if input is validated before use. The tool must be able to recognize the functions that could receive untrusted user input to be passed on within the application, as well as the functions that consume or interpret this input, and determine whether there is a function in-between that cleanses the data before consumption. This analysis helps identify injection problems (SQL, LDAP or command), helps with cross-site scripting (XSS), and verifies compliance with privacy rules (such as verifying sensitive data is not added to log files).

Control flow analysis

Control flow analysis checks the order of the program operations to detect potentially dangerous sequences, such as race conditions (time-of-check-to-time-of-use issues), secure cookie transmission failure, uninitiated variables, or misconfigurations of utilities before use (e.g. XML readers).

Structural analysis

Structural analysis examines language-specific code structures for inconsistencies with secure programming practices and techniques. It identifies weaknesses in class design, declaration and use of variables and functions, instances of dead code that won’t execute due to a false predicate, generation of cryptographic material (e.g. encryption keys) from insecure sources of randomness, and hardcoded passwords.

Semantic analysis

Semantic analysis is a grep-like functionality. In some limited ways, SAST tools are able to analyze a particular code within its context, such as detecting SQL injections through *.executeQuery().

Configuration analysis

Configuration analysis checks the application configuration files like XML or property files. It ensures that the configuration is aligned with security practices and policies, such as defining a default error page for the web application.

Advantages of SAST

Most vulnerabilities are created during coding and being able to detect them earlier in the SDLC, such as with SAST, makes remediation costs much lower than if the vulnerability is discovered after the release or worse, after a breach. SAST also ensures secure programming guidelines and standards are respected without actually executing the underlying code and is very useful for the issues that are detected with high confidence, such as buffer overflows or SQL injection flaws. The output is presented in a format that is readable by developers: the precise source files, line numbers, and even subsections of lines are highlighted.

Disadvantages of SAST

Despite their access to source code and potential for uncovering known vulnerabilities, SAST tools have limitations. Some vulnerabilities are difficult to detect automatically and pre-production, such as authentication problems, access control issues, weak cryptography, etc. In the case of access control, SAST tools can detect its absence but cannot verify if it is running appropriately in the case that it is implemented. Furthermore, few tools have configuration analyzers and thus, cannot find configuration issues when they are not represented in the code.

As far as results go, SAST tools often produce high numbers of false positives or false negatives. It is difficult to verify whether or not some identified issues are vulnerabilities indeed and if the SAST tool doesn’t find any issues, it does not mean that your code is secure.

SAST is also not able to detect runtime issues and many of the tools need the code to be compilable, which means they can be used only at a later stage of the development phase. To make matters worse, testers often find themselves not able to compile the code since they don’t have the right libraries, the compilation instructions, all of the code, etc.

Finally, SAST tools don’t scale well. The more applications and developers that need to work with a SAST tool, the more alerts, false positives, and backlog of unclear results there are. As the user base grows, the results have a greater impact on slowing down developers.

How to overcome SAST limitations

Despite their limitations, SAST tools significantly speed up the testing process for larger companies. For startups, they may be too cumbersome, and more lightweight, targeted efforts like security linting may be more appropriate. However, SAST tools do require human expertise to interpret and validate the findings. SAST is to be used mainly in tandem with:

  • Manual source code reviews, since the tools are still not able to detect some serious vulnerabilities
  • DAST tools, which can detect runtime vulnerabilities
  • Production security tools like ASM platforms