Dynamic Application Security Testing (DAST)

A DAST tool doesn’t require any insights into your application, such as which programming language was used to implement the application. This way you can improve your application security even when using niche programming languages.

How Does DAST Differ from Other Security Testing Methods?

In order to help you determine whether a particular security testing method is a good fit for your application testing environment, it’s important to consider what it has to offer as well as its limitations. Let’s examine the differences between each of these testing methods.

SAST vs DAST vs SCA

Static application security testing (SAST) focuses on code. It works early in the CI pipeline, scanning source code, bytecode, or binary code in order to identify problematic coding patterns that go against best practices. SAST is programming-language dependent.

Dynamic application security testing (DAST) is a black-box testing method that scans applications in runtime. It is applied later in the CI pipeline. DAST is a good method for preventing regressions and doesn’t depend on a specific programming language.

Interactive application security testing (IAST) is similar to DAST in that it focuses on application behavior in runtime. But IAST analysis is rather based on a combination of black-box testing, scanning, and analysis of internal application flows. The benefit of IAST is its ability to link DAST-like findings to source code like SAST. The downside of this approach is that it makes IAST programming-language dependent and can only be performed later in the CI pipeline.

Software composition analysis (SCA) focuses on third-party code dependencies that are used in the application. Software composition analysis is very effective in applications that use many open-source libraries. This method is also programming language-dependent.

Read more about SAST vs DAST, what is the difference and how to combine the two of them.

How Does DAST Fit with Other Application Security Testing Methods?

DAST fits best with application security testing methods that rely on static checks, like SAST and SCA, since it provides additional runtime insights to the static source-code analysis.

Often, SAST tools only look at single code snippets and don’t take their context into account. The code in one file can be seen as a problem even if code from another file that uses it takes care of all the issues. Security you implemented into your system can even run on a completely different computer. For example, A SAST tool would identify an unsanitized input as a problem, because it can’t correlate it with the sanitation that happens on the server right before the data is used.

DAST tools go into an end-to-end testing direction. They don’t know if the client code follows input sanitation best practices. DAST tools will look at the input and the output of your application; if your output is sanitized, they don’t care where in your architecture the sanitation happened.

But parts of your application that only fail on edge cases can be a blind spot to a DAST tool, since it only covers specific use cases, not theoretical inputs. This where SAST and SCA tools come into play. These tools look into the source code and check for problematic behavior that would remain under the radar if using a DAST tool alone.

For example, when a type conversion occurs, this can sometimes fail or deliver undesirable outputs. A DAST test case that only covers 10 inputs might report everything is okay, but a SAST tool would know a conversion method is prone to fail at specific values you’d never even considered when implementing your application.

DAST Pros & Cons

The nature of DAST tools, whereby the main function is to test an application in runtime offers a number of benefits but also has its drawbacks. Let’s review these more in depth to help you determine whether DAST is a good fit for your software project.

Pros:

• Fewer false positives: Because it doesn’t scan the whole application, DAST usually produces fewer false positives than SAST. This allows you to verify whether a vulnerability is real much faster and to see whether it can be prevented down the line.

• Language agnostic: DAST is the only security testing method that isn’t programming-language-specific. DAST doesn’t look at source code, bytecode, or assembly code; it just checks your system’s inputs and outputs. If your application is implemented with a niche programming language, DAST may be your only option.

• Quick retest of fixed vulnerabilities: DAST keeps regressions in check. If a security vulnerability is found and reproduced, the reproduction can be automated and added to the DAST test suite. This means every subsequent release will include the interactions that led to past problems. If these problems somehow come back again, DAST catches them before they’re released.

Cons:

• No code insights: DAST only looks at the inputs and outputs of your system. This makes it impossible to correlate discovered vulnerabilities with lines of code.

• Slower testing process: The requirement to execute and use the software can slow down the testing process, even with automatic testing methods. Clicking through a signup process with a number of input permutations just takes time.

• Results late in CI/CD pipeline: DAST resides on the far right of your CI/CD pipeline, because the execution of your application is required for DAST tools to do their work. This can become quite time consuming, especially if your application has grown over time.

• Manual testing may be required: If, for some reason, you can’t automate the execution and usage of your application, you’ll have to take the DAST check out of your CI/CD pipeline entirely and test the application manually for every release.

How to Successfully Implement DAST

Since DAST relies on the execution of your application, adding it to your testing pipeline isn’t as simple as adding SAST. While DAST can be made an automated process, the part that will be automated must first be scripted or recorded. This requires a process that needs to be followed after adding a DAST tool to your pipeline.

1. Sit Down with Your Users

A good starting place for implementing DAST is to sit down with your users and chronicle how they use your application. In addition to recording what they do, ask them to explain what they’re doing.

Users tend to forget what they’re actually clicking on in an application: Interactions that happen frequently become subconscious. While this helps the users to focus on their tasks, just because a user doesn’t think about something they clicked on, doesn’t mean this can’t lead to a problem.

2. Automate User Interactions

The next step is to use an automation tool for scripting the user’s actions. This may be a simpler endeavor for CLI and API applications than for GUI, but generally speaking, it’s possible for all of these.

3. Add the Test-Scripts to Your CI/CD Pipeline

When you finally have the most important use cases covered with automated interactions, you can run these scripts against your application while a DAST tool scans it. After the first DAST run, you can start fixing your security vulnerabilities.

4. Add Regression Tests to the Testing Suite

If you happen to find security vulnerabilities in your application’s day-to-day usage, you can add specific usage scripts to your test suite. This ensures that the issues won’t come back in the future.

Summary

While DAST is a reliable vulnerability detection method to have in your toolbelt, you won’t have all your bases covered using DAST alone. But sometimes it’s the only solution that’s left, for example, when you’re using a niche programming language to implement your application or closed-source packages or extensions to a common programming language.

Allowing a DAST tool to run can take quite some time, especially for complex interactions. And if you’re unable to set up automation for such interactions, you’ll be required to do them manually prior to every release, which may take days or even weeks to complete.

When comparing SAST versus DAST, SAST may seem like the better choice overall, since it can be used earlier in the development process when it is easier and cheaper to fix detected security issues. But DAST tools certainly offer some great benefits.