SAST vs. DAST vs. IAST: Security testing tool comparison

Static application security testing

SAST comprises the tools and technologies designed to check code for flaws and vulnerabilities. This method is a form of white box testing -- its tools sometimes are called vulnerability checkers -- that looks for problems in the code.

A SAST tool, for example, might identify weak random number generation code, find potential buffer overflows, spot SQL injection possibilities, flag cross-site scripting flaws and identify other potential trouble spots that malicious actors could exploit. Development teams regularly use SAST tools to enforce compliance with established coding formats and standards. This process can include everything from indentation to variable naming conventions and any other formatting related to the way developers write code.

SAST tools work by scanning code at rest (no human or program executes the code). The tool searches the static code line by line and instruction by instruction, comparing each against an established set of rules and known errors. SAST tools typically include a wide range of known errors out of the box, and additional issues can be defined as needed and added to the test regimen. SAST tools are typically selected with consideration of:

• the development language (if the development team programs the application in one language, the SAST tool should scan that language);
• the list of vulnerabilities the tool covers and the ability to add custom criteria;
• the accuracy (number of false positives) of the tool; and
• the compatibility of the tool with existing CI or other development tool sets.

SAST tools are usually included with development tool sets, and IDE vendors may even include such tooling as part of those platforms. Developers should invoke SAST when they write code. Accordingly, SAST tools will discover security vulnerabilities early in the development cycle before any human or program executes the code. However, it's important to note that SAST tools can render false positives. SAST users should have enough coding, design and security savvy to recognize false positives or make suitable changes to the code to avoid false positives.

SAST helps the business and application development effort by moving security testing earlier into the development cycle. Errors at this early stage of development are often the result of simple coding errors or other common vulnerabilities. They can typically be fixed easily and inexpensively at the coding stage.

SAST, however, is only for static code. The method cannot handle all vulnerabilities, and it is not suited to runtime (operational) or configuration vulnerabilities such as proper authorization and authentication. Accordingly, development teams often use SAST in conjunction with other security testing tools. In addition, false positives can be common, so developers waste time chasing false alarms. The tool points out possible problems; it's up to developers to confirm, validate and fix them. This extra work can put demands on the development team -- especially in rapid development environments where time is at a premium.

SAST vendors include Coverity's Synopsys, HCL AppScan Source, SonarQube, Kiuwan Code Security, AttackFlow and Micro Focus Fortify Static Code Analyzer.

Dynamic application security testing

DAST represents the array of tools and techniques used to check for vulnerabilities in running applications, which are often web-based apps. This method is a type of black box testing. Unlike SAST, which sees the code base, DAST has no knowledge of the underlying code. Instead, the DAST tool is designed to inject or feed faulty or malicious data to the software.

DAST is well-suited for finding server configuration and authentication problems, along with flaws visible only when a user logs in. For instance, the tool might attempt cross-site scripting or try feeding alphanumeric input to dialogs that expect numerical input. The goal is to see how the software handles errors.

Ultimately, DAST works to test software from the outside in, testing a running software build in the same ways that a hacker might probe for exploitable weaknesses. Although the word dynamic in the name indicates that the application is running, the application runs in a staging environment -- not in production.

DAST tools are basically input simulators. They provide predetermined inputs to the software under test. The predetermined inputs are test cases that a team usually designs to simulate malicious attacks on the application and compare the expected output against the actual result. If there is a difference between the expected and actual result (or the app responds to an input when it shouldn't), the software may be exhibiting a flaw that demands further investigation.

DAST does not look at the underlying code, so the method cannot point to specific points in the code. Instead, DAST reports on actions, inputs and outputs to indicate possible vulnerabilities. For example, DAST is extremely popular in web application testing, and teams routinely use the method to inject malicious data to uncover possible injection flaws. In addition, DAST simulates random user behaviors to check unexpected vulnerabilities. Teams usually select DAST tools by considering:

• the level of automation the DAST tool provides (its ability to automate, schedule and run manual scans as desired);
• the scope of vulnerabilities the tool covers (such as support for the OWASP Top 10 vulnerabilities);
• the level of customization (configuring the tool for specific or complex tests); and
• the tool's compatibility with existing CI/CD or other development tool sets.

DAST tools may demand more time and security expertise than SAST tools. Because DAST doesn't scan in the conventional sense, its performance cannot be measured in lines per second or other objective metrics. Instead, the tool can provide only an input or attempt an action at specific points in the application's operation. It takes time for applications to load, run and reach those specific points where probing can take place. Thus, DAST testing can take more time. And because DAST requires a solid understanding of the application and its operation (to configure and administer test conditions), effective DAST use often relies on developers with extensive security expertise and knowledge of both the application and its dependencies.

DAST tools can be efficient investments. DAST is unconcerned with underlying code; the DAST tool is not platform-specific, so one DAST tool can potentially work for all applications. DAST operates on a software build from the outside, which makes it ideal for finding configuration errors and oversights that are easy to miss. Where SAST tools may produce large numbers of false positives, DAST tools tend to report low false positives because tests and test criteria are designed to focus on real and identifiable vulnerabilities. For example, if an application logs in a user with blank or incorrect credentials, there is no doubt that's a security flaw.

But DAST also suffers from some notable limitations. DAST depends on a large manual effort to write and manage test conditions. This limits DAST scalability and utilization without a substantial and ongoing investment of test development time and effort. Time is also an issue with DAST; the number of test cases and the speed at which an app can run mean comprehensive scans could take days. Finally, DAST results don't relate to code, but rather to conditions and results. Accordingly, developers need to review and identify the underlying causes of flaws DAST report.

DAST vendors include open source ZAP, which is built on ZAP and is well suited for CI/CD workflows; Detectify; Netsparker; Rapid7's InsightAppSec; and an enterprise application security platform from Veracode.

Interactive application security testing

IAST combines some of the best characteristics of both SAST and DAST. Its objective is to deliver application security testing from within the application itself -- often while the application is in development. When properly configured, an IAST tool can:

• access all the application code;
• gather information about control and data flow at runtime;
• access configuration information;
• oversee web (HTTP) traffic; and
• access application components, including libraries, frameworks and data within back-end dependencies.

In effect, IAST offers a comprehensive view into an application and its environment to address more code, offer more reliable results and identify more security flaws than SAST or DAST.

IAST software agents analyze an application's operation, search for vulnerabilities, check performance and feed detected problems directly into a tracking tool. Because a development team can apply such software agents anywhere in the development cycle, IAST can function throughout development. This could start within the IDE during coding to check the code base, follow into software testing and validation to report on performance and flaws and continue while the built application is rolled out into production for ongoing security monitoring. A development team should select IAST tools after careful consideration of:

• the development languages the team is using (if IAST scans code, it must understand the language);
• the scope of coding and operational vulnerabilities the tool covers (and the ability to add custom criteria);
• fast performance (often operating in the background) and low rate of false positives;
• support for major compliance and security standards (such as PCI DSS, GDPR, SANS/CWE and more); and
• ease of deployment and integration with existing development workflows and CI/CD tool sets.

IAST tools can exist across the entire development cycle and into production. They can be useful for developers who write the code, testers who validate the builds and even the operations staff who deploy the build. Vendors emphasize ease of installation and use. Even so, some amount of security knowledge is essential -- whether to help understand the tool's results or follow resulting trouble tickets to make rapid and effective fixes.

Like SAST offerings, IAST tools can scan code. This enables IAST technologies to support early discovery and remediation of coding problems, many of which developers can fix at minimum cost and delay. Perhaps more compelling, IAST can pinpoint operational problems more specifically than DAST tools. DAST knows when there's a flaw but doesn't see the underlying code. IAST sees both the code and the operation of the software, allowing reports to show the actual operation or corresponding point in the code where an operational vulnerability occurs. This helps speed location and remediation of operational problems in the code.

The primary concern with IAST is the use of agents and instrumentation. While usually small and often innocuous, these code segments can potentially affect the operation of an application and reduce performance. The most performance-sensitive applications might have issues when IAST tools are applied. This problem has long been a concern for software agents.

IAST vendors include Acunetix, Checkmarx CxSAST, Veracode and the Seeker tool from Synopsys.