Static application security testing (SAST)

What is static application security testing?

The term static application security testing (SAST) applies to security testing performed on static code, not on a running application. Note that the term SAST can refer both to the security testing methodology and to tools that use this approach.

Other application security (AppSec) terms used to describe static application security testing are white-box testing, static code analysis, secure code review, and inside-out testing.

Types of static application security testing

There are three primary types of static application security testing:

• Source code analysis – the testing tool analyzes the original source code of the application, for example, the C++ source code.
• Bytecode analysis – the testing tool analyzes the intermediate code. This is possible only for platforms that create bytecode, such as Java or .NET.
• Binary code analysis – the testing tool analyzes the final compiled code of the application.

Note that most contemporary SAST solutions are designed to test the security of web applications, mobile applications, and APIs. However, there are also SAST tools for testing desktop/thick applications.

How does SAST work?

Static application security testing tools work by running checks on the application code. A tester or an automated environment points the SAST tool at specific files containing application code (source code, bytecode, or binary code, depending on the SAST type) and then the tool performs a series of checks on these files. If it finds a vulnerability, it records the exact location and additional details (dependent on code type) and provides this information to the user.

Static analysis tools may also test dependencies or even work on the entire codebase repository, not just single files. Some SAST tools can even be integrated into the development environment and run checks in real-time, as the developer writes the code.

The benefit of source code SAST is that it is able to pinpoint issues down to the exact line of code or even a specific location within the line. For bytecode and binary code SAST, some tools can reverse-engineer the intermediate code to locate the underlying problem in the source code.

Note that application security tools, unlike anti-malware tools, do not perform remediation. Their job is only to find typical security issues in the application, such as SQL injections, cross-site scripting (XSS), or buffer overflows – not to fix them. Any security risks that are found need to be eliminated manually by development teams.

Advantages and disadvantages of static application security testing

Static application security testing should be a part of a complete security testing program that includes other web application security testing methods, such as dynamic application security testing (DAST) (also known as black-box testing), interactive application security testing (IAST), software composition analysis (SCA), and manual penetration testing. SAST has a few advantages over other testing methodologies.

• SAST solutions can test all application code, no matter whether it is already linked to the main application or not. By contrast, dynamic and interactive testing requires the app to be at least functional. This means that SAST scans can be applied earlier than other methodologies.
• SAST is perceived as the testing method that provides the most accurate location of the root cause of a vulnerability. However, this capability is now also found in modern IAST solutions, such as Invicti IAST and AcuSensor, which are also able to point to the exact cause of the vulnerability in bytecode or even the source code.

Static application security testing also has some disadvantages in relation to other application security testing methodologies.

• SAST tools are limited to specific programming languages. In multi-language application development environments, teams may need to buy, use, and coordinate several different SAST tools from different vendors just to cover their entire codebase (or at least most of it).
• Static application security testing is extremely prone to false positives because the scanner cannot fully understand the runtime conditions or the developer’s intent. This is especially noticeable in tools that analyze the application source code. SAST solutions also cannot prove that a suspected security vulnerability is indeed a real issue. For all these reasons, SAST scans are often followed by manual validation.
• You can only use SAST tools on applications that are in development – not legacy applications or software that is already deployed to production. Combined with the inability to detect any runtime (dynamic) vulnerabilities, this means SAST cannot be used in later stages of the software development lifecycle (SDLC).

Due to the above limitations, it is best practice for businesses to avoid relying on SAST as their only application testing methodology. When SAST is used, it is recommended to pair it DAST or IAST solutions.

SAST accompanying technologies

The sole function of static application security testing is to scan application code and find vulnerabilities. However, in most environments, that is not enough. To deal with this, many SAST tools offer extra functionality or come bundled with accompanying software to provide the following functions:

• Vulnerability assessment: In larger organizations, the number of vulnerabilities can be in the thousands, making it impractical for security teams to manually verify endless lists and prioritize issues. Vulnerability assessment solutions automatically assign priorities to vulnerabilities discovered by SAST based on different factors such as severity, ease of exploitation, or even the business importance of a particular asset. This lets security teams focus their remediation efforts on security risks that are most likely to lead to severe consequences such as a data breach.
• Vulnerability management: If the number of vulnerabilities is large, it is almost impossible to manually track issue resolution status. That is why SAST tools need to be tightly integrated with issue-tracking solutions that allow security teams to manage vulnerabilities.

Many SAST providers offer bundles that include not just vulnerability assessment and vulnerability management (usually as separate applications within the same environment) but also other types of application security scanning, such as DAST and IAST.

Note that unlike in the case of DAST, there are a plethora of open-source/free SAST tools for different types of applications and different languages, including GitHub Advanced Security, OWASP ASST, OWASP WAP, and dozens more. Most of these applications are code quality scanners with some security checks built-in. They are usually limited in their scope of security testing and require manual integration into your SDLC. Therefore, they are best treated as additional tools and are generally not suitable for larger business environments.

How to use SAST?

Due to the inherent limitations of SAST, the best way to use static security testing is by combining it with DAST and/or IAST. Used on its own, SAST will miss many vulnerability classes and often won’t cover your application languages. For example, if you have a SAST tool for Python but not for JavaScript and you are building a modern single-page web application based on a UI framework such as React, your SAST will only test the Python back-end, not the JavaScript front-end.

The best time for SAST analysis is at the earliest stages of the development process. If the SAST tool integrates into the development environment, for example via an IDE plugin, it gives you an early start advantage that no other application security solution can offer. The later you move in your DevOps/DevSecOps workflow, the less you should rely on SAST scanning.

When using SAST in a CI/CD pipeline, keep in mind that the high rate of false positives typical for most SAST scanners makes it very nearly impossible to use SAST to automatically fail builds. In most cases, you will be limited to providing the developer with a SAST security report or issuing a warning. And while you can fine-tune SAST tools to get rid of at least some false positives, this often results in fewer real vulnerabilities being found.

Frequently asked questions

Related blog posts

• DAST vs. SAST: Fact check on static and dynamic application security testing

Written by: Tomasz Andrzej Nidecki, reviewed by: Zbigniew Banach