When It Comes to Application Security Testing, Should You Go Dynamic or Static?

There are two main categories of application security testing: dynamic and static. They can be thought of as testing from the outside-in and from the inside-out, respectively.

Dynamic testing is performed as an application is running and focuses on simulating how an outside attacker might access that application and associated systems. Static testing, on the other hand, examines the code itself and related documentation, often throughout the actual development process, to try and discover potential vulnerabilities before the application reaches production.

Should you use dynamic application security testing (DAST) or static application security testing (SAST)? In truth it is not an either/or situation, as DAST and SAST are complementary and evolved indivually. First let's take a look at the key differences between them.

Black Box vs. White Box: a question of dev lifecycle methodology?

SAST and DAST can also be thought of using common infosec terms black box and white box. White box testing is when you have full knowledge of the IT stack, including the internal structure, design, and implementation of the application and its underlying hardware or services. Black box testing is the opposite, you are simulating an outside attack and should have no knowledge of the underlying systems.

Whether you use SAST or DAST might depend on your software pipeline and how you approach delivery. Obviously security plays a role in any software development process. But if you practice agile DevOps or Continuous Integration methodologies, you are more likely to have DevSecOps with security integrated into the continuous improvement process and continuous delivery pipeline. In this case, you’re more likely to be using SAST as well as DAST. If you’re still purchasing or developing software and rolling it out in the more traditional waterfall method, you may only need to use DAST.

Both DAST and SAST can be implemented during the QA and Production phases of app delivery, but only SAST can be used during development itself. (This ought to be pretty logical since dynamic testing occurs only when the app is being executed.)

Key Differences Between Dynamic and Static Testing

SAST scans must know the language(s) used in development as well as the app framework in use. When choosing a SAST provider or scanning technology, make sure it supports your technology stack. DAST, however, is largely technology-independent, using HTTP traffic to probe and attack.

With static testing taking a white box approach, it can be considered more thorough and potentially more cost-efficient, as it locates bugs and vulnerabilities at an early stage in development, so they can be remedied faster and before reaching production. The ideal resolution with static testing is to catch a security vulnerability, say a potential backdoor access point, at a review meeting. This vulnerability can then enter the project backlog, avoiding multiplying costs that could have occurred if the error made it all the way into production.

Static testing offers advantages because of its access to the raw code, including being able to read unreachable or undeclared code and uncalled functions. It locates the exact spot of vulnerabilities within the code itself, allows faster remedy, and reduces the cost of fixes.

However, static testing can be more time consuming, especially if manual code reviews are paired with automated solutions. It also may miss vulnerabilities related to the runtime environment itself, as it focuses on the code. If DAST is sufficient, SAST is also an added cost.

Dynamic testing has the advantage of analyzing apps for which you do not have access to the code, such as those you purchase rather than develop in-house. It can also verify findings from SAST, or conversely locate false positives that turn into real vulnerabilities once executed. It may be more difficult to fix the vulnerability if it is code-related, as it can take longer to trace it back to an actual location within the code. Automated tools are also heavily reliant on the rules they are fed to direct the scan.

Which method should you use?

Ideally, a combination of SAST and DAST would be best to cover all your bases when it comes to the security of your applications. While SAST can be more easily implemented as part of your DevSecOps pipeline, adding DAST once you enter production will help mitigate potential vulnerabilities in the rest of the stack outside of your code.

For most commercial software deployments, DAST will be your only real option, as you do not have the choice to modify or view the source code. If you are not developing from scratch, DAST is likely sufficient to locate and remedy any vulnerabilities from within the runtime environment.