In the application security testing domain, the debate, if static application security testing (SAST) is better than dynamic application security testing (DAST) or interactive application security testing (IAST) is heating up. But is this really the right question to ask?

I think it is not. Static approaches (e.g., SAST) and dynamic approaches (e.g., DAST or IAST) to application security testing have fundamentally different properties. Thus, the important question is, how can we combine SAST and DAST/IAST to make an application security program as effective and efficient as possible.

The image shows an abstract architecture of a modern, multi-tiered application that, e.g., comprises

• A front-end tier, e.g., a web application written in JavaScript that is executed in a web browser (which, itself runs on an operating system on the end users’ computer),
• the application tier, e.g., a Java application running on an application server (runtime container) such as Tomcat that may contain parts written in another language, e.g., C/C++.
• the backend tier that could include legacy systems or database systems for providing persistence.

Such an application is not executed in isolation. On the contrary, such applications are executed in a complex environment that may include other defensive and active security technologies such as certain operating system configurations, network firewalls, or web application firewalls. Thus, the overall security risk of operating such an application depends on all aspects of this complex environment.

Static Application Security Testing (SAST)

Static Application Security Testing (SAST) is a technique that analyzes the source code or byte code of your software without actually executing it (as SAST analyzes the internal details of a program, we call this a white-box test). Thus, it can achieve a (nearly) full coverage of a piece of code. Usually, SAST tools are not able to analyze flows across several tiers of a multi-tiered architecture: actually, the extent to which the environment (e.g., libraries, network interface, execution environments such as the web browser or a runtime container) are specified influences the quality of the SAST results significantly. Thus, SAST tools are good to cover the different tiers of our example application individually (“horizontal coverage”).

Moreover, as SAST tool analyze the source or byte code, they usually only support a limited subset of programming languages (or binary architectures). Thus, to cover as many tiers and programming languages used

The strengths of SAST include the ability to use it really early in the software development process (and, thus, to fix vulnerabilities before they reach your quality assurance department, or worse, your customers) as well as the ability to provide very detailed instructions for fixing a vulnerability.

Testing the Running Application: DAST and IAST

Dynamic Application Security Testing (DAST) and Interactive Application Security Testing (IAST) share one property: they analyze a running application. Thus, in contrast to SAST, they analyze an application in the context of its actual runtime environment, from the client application down to the backend systems. Thus, to stay in our picture, they can achieve a “vertical coverage”, i.e., also detect vulnerabilities that only occur in the interplay of different tiers or in the interplay of our application with its environment (e.g., the underlying operating system, backend systems, or a WAF).

As DAST and SAST obverse a running application, they can only detect vulnerabilities that are observable changes in the behavior of the application: The vertical coverage depends on the number of different execution traces and, thus, is usually much lower compared to SAST.

As IAST is not yet a widely used technology, let’s briefly compare DAST and IAST.

DAST

Dynamic Application Security Testing (DAST) treats the application under test as a black-box, i.e, it only injects input into external interfaces and observes the behavior of the application by, again, only observing the external outputs. Thus, DAST tools can only point to vulnerabilities but, in contrast to SAST, are usually not able to provide information to developers on how to fix a detected issue.

Moreover, as modern applications are usually using rather complex client protocols, is challenging to support the necessary interfaces. Finally, DAST tools might inject test data that, not immediately recognizable, might harm backend systems (e.g., by storing invalid data in a database).

IAST

Interactive Application Security Testing (IAST) tries to combine transfer some of the advantages of SAST to the world of dynamic testing. IAST is based on the idea of instrumenting the application that should be tested (technically, it might, e.g., for Java, also sufficient to execute the application in a modified runtime environment). As an IAST tool knows some internal details of the application under test, this approach is classified as gray-box-testing).

First, the instrumentation allows to observe the behavior of the application under test in much more details and, e.g., block bad inputs from entering back-end systems or to detect vulnerabilities that pure DAST would not be able to detect. Second, the detailed knowledge of the executed (and not-yet-executed) parts of the applications allows for generating test inputs that stimulate not yet executed parts of the application and, thus, increase the “horizontal coverage”.

Combining SAST and IAST/DAST

Clearly, the goal of a comprehensive security testing strategy is to maximize both the horizontal coverage and the vertical coverage. To achieve this, combing static and dynamic security testing approaches is necessary. Thus, while SAST can be considered a workhorse in secure application development (see, e.g., [1] for an experience report on using SAST at SAP), a holistic security testing strategy needs to integrate both approaches [2].

Besides achieving a better overall coverage (both in terms of the coverage of the application under test and in terms of the coverage of security risks/vulnerabilities), SAST can help to optimize the use of IAST (or DAST) tools and vice versa. For example:

• if a certain security risks (or vulnerabilities) are detected effectively by a dynamic testing approach, you might want to exclude checks for these risks in your static tools (and vice versa). Using static and dynamic tools should not result in doubling your efforts.
• findings from dynamic testing can be used for improving static checks (both to minimize false positive rate and to improve minimize the false-negative rate).

What should I do?

If you want to implement a holistic software security program, there you definitely should look on static and dynamic approaches. Their properties are so different, that depending on your most important security risks, the technologies that you use for developing your applications and, last but not lest, to your organizational approach (e.g., who is using the tools). Choosing the right tool for your needs is not an easy task; you might recall our earlier post on “A User-Centered Classification of Security Testing Tools” that discusses a few of those challenges.

Still, one thing is true for all tools: you need to work with them and adapt them to your needs. None of the more powerful application security testing tools that I am aware of, is a “of-the-shelf” solution that works effectively and efficiently without customization. Also, your needs and priorities will change over time. Thus, as a general rule of thumb: start with one tool (or a small number of tools) tool and gain your own experience, constantly monitor the use to learn the weaknesses of your current setting and improve.

• If you are already using SAST but do not use a DAST or IAST tool, I would strongly recommend to look into IAST. It is a promising technology seems to be more appropriate than DAST for software development organizations.
• If you are already using DAST you might not feel an urgent need to look at IAST tools. But if you are not yet using SAST, I would recommend to look into SAST tools that address risks not covered by DAST tools (e.g., checks for hard-coded secrets).
• If you only rely on penetration tests, I would recommend to look into DAST tools (here, you might be able to leverage the penetration test expertise and automate parts of the penetration tests) or SAST tools (again, the choice of SAT vs. DAST vs IAST depends on your personal situation). Please try to bring you security testing closer to developers to detect and fix security issues as early in your software development life-cycle as possible.

Finally, there is more to security testing than only SAST, DAST, and IAST; see, e.g., [3] for an (academic) overview of different security testing approaches. You might ask yourself why I am only mentioning penetration tests in the very last paragraph. That’s a story for a future blog post.

References