Why DAST Should Be
Your First Application
Security Priority

There are three standard tools in a security leader’s arsenal for tackling application security testing  – Dynamic Application Security Testing (DAST), Static Application Security Testing (SAST), and Software Composition Analysis (SCA). 

One of the conversations we come across often here at StackHawk is, “Which tool should I start with?” This is true for organizations of all sizes  –  from those just beginning to build out their AppSec program to those working on retooling their current approach to be more developer friendly. 

While a comprehensive security program will have all three in place, we are big believers that DAST is the best place to start an application security journey. 

Ready on to see why teams can get the most out of a tool by starting with DAST.

Why We ❤️ DAST

Of the three security tooling types available, teams can see the greatest return on investment by implementing DAST. There are a few reasons for this:

1. DAST simulates how bad actors access your applications. The types of attacks that a DAST scan can find simulate a bad actor attempting to steal or manipulate sensitive data, deface a website, or plant malware on the site. If you are implementing a tool to protect yourself from external threats, DAST is the best option.

2. DAST tests the running application. Neither SAST nor SCA have the proper context of how the application being tested actually works. Because DAST is testing the running application with bad inputs to see how it behaves, users get more accurate results.

3. DAST finds vulnerabilities that your team is writing. While testing open source libraries is important, 69.1% of companies have more vulnerabilities from their own application development vs. the use of open source. This means your first consideration when it comes to security testing should be the code your team is writing with a tool like DAST, not the libraries you are using.

Where DAST Has Historically Fallen Short

That being said, DAST has not always been a user-friendly tool. Historically it came with operational hurdles that made it a tool that frustrated both security and developers. 

Until recently, DAST had the following struggles:

1. Difficult to automate. DAST was typically used by penetration testers to run manual audits that could take days or weeks. Until recently there have not been good options for fitting DAST into the modern development workflow.

2. Testing the front end in prod. Because DAST was difficult to automate, that meant security teams and pen testers were testing the application in production. One of the biggest hurdles with this approach is that it only tests an app’s front end. 

3. Coverage for microservices and modern apps. DAST technologies were created at a time when application architectures were much simpler. Unfortunately that means for today’s teams that are building microservices architectures with backing APIs, there is no good way to test these individual components for vulnerabilities.

4. Difficult to take action on findings. Perhaps the most frustrating part of DAST is that it only tells teams that certain vulnerabilities exist versus pointing to the exact line of code causing the vulnerability. The frustration from this issue is compounded by the first two items on this list. By the time vulnerabilities are found and shared back with developers, it may be weeks or months since they worked on the code that was tested. They have moved on and forgotten about that particular portion of the application they were working on, and as a result, the fix requires mental backtracking. 

How StackHawk Is Different

When we started StackHawk, we were well aware of the typical challenges of DAST. So we created a DAST tool that was easy to deploy, easy to automate in CI/CD, provided complete coverage for APIs, and had developer-friendly features that equipped engineers to fix vulnerabilities immediately.

If you are hesitant to try DAST because you have been burned by other tools before, give StackHawk a try for free and see what you think. 

But enough about us, let's get back to the other types of tools available.

Why Teams Like SAST

If you are trying to find vulnerabilities in the code your team is writing, the alternative to DAST is SAST. SAST works by analyzing an app’s source code and looking for vulnerabilities in the code as it is written. 

By analyzing the source code instead of the running app, users are able to get broad coverage, even if that code is difficult to execute programmatically. Additionally, a SAST scan can be done relatively quickly because the scanner is not interacting with a live app instance. 

Perhaps the most loved feature of SAST is that it pinpoints to the exact line of code causing the vulnerability. 

DAST vs SAST

At StackHawk, we prefer using DAST as the foundation of an application security program over SAST. We are obviously biased, but we think the quality of results from a DAST scan are of higher quality and better protect team from vulnerabilities making it into the wild. 

The benefits of DAST over SAST we see the most are:

1. DAST is much less prone to false positives. If DAST finds a security bug in the application, it almost certainly exists. By producing less false positives, security teams can spend less time validating if findings actually exist, and developers can get a more focused testing experience.
   

   

   

2. DAST can handle complex application architectures. SAST has difficulty finding vulnerabilities when an app has multiple layers (e.g., proxies, middleware) or is composed of microservices. If we were building apps in 2004, this wouldn’t be a problem. But if your team is building modern apps, SAST may not be your best option.
   

   

   

3. SAST is language dependent. If you are writing an app in C++ or python, this is likely not going to be a problem for you. But, if you are writing an app in Kotlin, Rust, or any newer language, you are likely going to be short on SAST options for your shiny new app.

DAST + SAST

While both DAST and SAST have their drawbacks when used individually, combining the tools together can make security testing more efficient. By leveraging DAST and SAST offerings that correlate findings from DAST with the line of code causing the vulnerability as reported by SAST, teams can eliminate noise and streamline fixes.

Using these two tools together, teams can:

• Prioritize Findings. DAST and SAST testing works together to identify the high-priority, exploitable security issues in your code. No more manual correlation across tools, and no other software required.

• Accelerate Fixes. Quickly identify where the issue exists in your codebase, down to a single line of code. Developers can take action on a finding without extensive research or time wasted trying to identify where it lives in the codebase.

• Drive Efficiency. Eliminate context switching across tools and give your team a comprehensive understanding of application and API security issues with a single look. Save time and keep your developers focused on software delivery.

We of course are biased, but we think our integration with Snyk Code provides teams with a best-in-class way to make security testing part of the developer workflow.

Why Teams Like SCA

Software Composition Analysis, or SCA, is another type of security testing tool that finds vulnerabilities in open source components that your team is using.

Teams like using SCA because it is quick to run and provides broad coverage. SCA is also a newer class of tool that is built to enable developers to remediate vulnerabilities before production. 

Most SCA tools integrate with major CI/CD providers, run a scan at the PR, and provide a summary of actionable findings to developers if the application contains any vulnerable dependencies. The tools provide guidance on how to remediate vulnerabilities (most often by updating the version being used), and developers can get back to building features. 

If you are working on a new project, it is really simple to update versions of open source components without breaking changes. For legacy projects, this can be much trickier, but still worth the effort. 

DAST vs SCA

As we mentioned above, most companies have more vulnerabilities from their own application development as compared to open source components. This means your first consideration when it comes to security testing should be the code your team is writing, not the libraries you are using. 

DAST and SCA are not substitutes for one another. If your team is looking to prioritize a rollout between tools, our recommendation is DAST first, so that you can be sure the code your team is writing is secure.

That being said, open source code is pervasive. Almost 99% of audited codebases contain some amount of open source, and the average percentage of open source in those code bases has almost doubled — from 36% in 2015 to 70% in 2019. 

Your work is not done after securing your own code base and SCA is a great follow-up tool to add to your pipeline. 

There are great benefits to using DAST and SCA together. Where DAST can find a vulnerability in a running application, SCA can help you validate that finding and pinpoint where it lives in an open source library while providing quick remediation guidance which is typically a version upgrade. 

You can see an example of that in action in our joint webinar with Snyk. 

Get Going with DAST

Implementing new security tooling in any organization is a big decision. It is important that you think through what types of vulnerability protection you are looking for, who will be involved in testing, and how the tool fits into existing workflows. 

Based on how you answer those questions you can determine if DAST is the best place to begin, which we strongly believe is the case for most teams. 

Teams that are implementing StackHawk in their pipelines are seeing operational gains in their security team, protecting their APIs from vulnerabilities, and reducing risk across their organizations. 

You can set up a StackHawk account and get scanning for free today. Teams are able to get from account sign-up to a completed scan in CI/CD in 20 minutes. So give it a go, and feel free to drop us a line if you run into any hurdles.