Debunking the top 5 myths about DAST

Note that, strictly speaking, dynamic application security testing refers to any kind of security testing that’s performed on a running application, including manual dynamic testing. In practice, though, “DAST” or “DAST tool” is now the common term for an automated web vulnerability scanner.

Myth #1: DAST doesn’t find anything

The very first DAST tools (we’re talking the early 2000s) were created as an aid to manual testing on static pages, not as standalone solutions, so they were designed to overreport to give the pentester a rough idea of where to investigate. They also needed manual configuration by an expert user to fine-tune them for a specific site or application, but they were still mostly recon tools that scanned “a mile wide and an inch deep,” as the saying went. Several of these early black-box testing tools became commercialized and cemented the misconception of DAST limitations, especially as websites and applications became more dynamic and those legacy tools were left barely scratching the surface.

Acunetix and Netsparker were among the first dedicated web vulnerability scanners to run fully automatically and deliver reliable and usable results, with Invicti building on that legacy with advanced crawling, automated authentication, proof-based scanning, discovering and testing APIs (application programming interfaces), and more. Today’s premium DAST tools can examine your entire web attack surface and then safely test it for exploitable vulnerabilities while also identifying outdated and vulnerable components in the application and tech stack. Crucially, they crawl and test pages using a full embedded browser engine, so if a user can open a page, the DAST can scan it—while also scanning things a user wouldn’t normally access, such as API endpoints.

Learn more about API security testing in the real world

Myth #2: DAST only gives you probables and false positives

The legacy of those early scanners also lingers in the perceived low quality of DAST scan results. Designed to examine relatively simple static web pages and flag anything that could need manual investigation, those early tools were never intended for automation without an expert first sifting through the results. You could say that legacy DAST was deliberately built to return mostly false positives—but as web applications became exponentially more complex and numerous in just a few years, getting accurate and automatable results became a must.

This prerequisite was the foundation of proof-based scanning—the deceptively simple idea that the way to deliver unquestionably accurate vulnerability reports is for the DAST scanner to actually exploit a security vulnerability and bring back proof of vulnerable application behavior. This approach underpins all of Invicti’s testing methods and tools, from DAST and IAST (interactive application security testing) to runtime SCA and API security, but to do this safely, efficiently, and repeatably took well over a decade of non-stop development and refinement. While this is only possible for security checks that execute test payloads and can elicit a reaction from the target app, the same accuracy requirement is applied to all other automated tests performed by Invicti tools, making the vulnerability reports directly usable in remediation tickets—and in the development pipeline.

Learn how Invicti finds vulnerabilities with proof-based scanning

Myth #3: DAST can’t be used in the development pipeline

In the waterfall software development process, the traditional place of all testing, from functionality to security testing, was in the QA phase after development was complete. With the rise of DevOps, most testing was heavily automated and integrated into the pipeline, but early DAST scanners weren’t built for automation or speed. These tools still had to be run manually and their results analyzed by security experts, often coming back to developers as unclear issues and at a late stage, requiring costly and frustrating backtracking across the otherwise automated pipeline. 

Fortunately, this is no longer true, and organizations can and do use DAST in their DevOps pipelines alongside SAST and other security testing tools. It is still true that a DAST scan requires a running application, but it doesn’t always have to be a full build or full scan. With tools like Invicti, any runnable prototype can already be scanned, and if you’re only updating one page in a larger app, you can run an incremental scan on just the updated part. It’s now also common to have containerized deployments where the “runnable app” requirement is satisfied efficiently and automatically. With reliable results and scan performance that’s an order of magnitude higher than with legacy tools, a good DAST is indispensable in any software development lifecycle (SDLC) to build DevSecOps.

Learn more about using DAST in the SDLC

Myth #4: We have a SAST already, so we’re secure

While this is slowly changing, the cybersecurity market is still dominated by established network security and SAST (static application security testing) vendors, so the message many organizations are getting is that DAST is no big deal, just another box to check. In reality, many of these vendors underestimated the importance of web application security already in the early 2010s when the world started shifting to web software and the cloud, so they are now playing catch-up to dedicated DAST vendors. One of the misconceptions here, reinforced by compliance requirements that specifically list source code analysis, is that a SAST tool is all you need to build and release secure software.

Using static analysis in development is definitely a best practice, but it’s not nearly enough to give you full security testing coverage across your entire web attack surface. The confusion comes from two different understandings of “coverage.” Testing in development is about code coverage, meaning how much of your application source code has been tested, and this is what SAST coverage refers to. But a running web application exposes a far greater attack surface than just your SAST-covered first-party code, so DAST coverage refers to testing as much of that surface as possible—covering runtime issues, misconfigurations, dynamic dependencies, frameworks, APIs, and more across both first-party and third-party code.

SAST tests if your source code is secure. DAST tests if your whole application is secure. So you need both DAST and SAST, ideally on the same platform.

Myth #5: We have a network scanner and also do pentesting, so we don’t need DAST

“I scanned our website and didn’t find anything, so we’re secure” is something you will often hear when people mistake a network scanner for a web application security tool. Security professionals may laugh and shake their heads at this point, but try searching online for “online security scanner” and marvel at the variety of tools that comes up. A network scanner and a web vulnerability scanner (a DAST) are different tools for different purposes. If your web server is configured correctly and securely, a network scanner will give it the green light—but it can’t tell you whether your customer portal page is vulnerable to SQL injection or cross-site scripting (XSS) or one of your business apps has an SSRF vulnerability in the /api-v2/users/ endpoint.

Penetration testing, on the other hand, finds the same types of issues as a DAST but on a different scale and time frame. Most pentesters will start an engagement by running a good quality DAST tool (among others) and then dig deeper to look for exploitable gaps to report. Having the expertise of penetration testers is crucial to finding more advanced vulnerabilities, but how often do you run a penetration test? Can you run it after every commit in your pipeline for CI/CD (continuous integration/continuous deployment)? Could you even afford to run it that frequently? With a good DAST tool, you can have always-on automated dynamic security testing in your pipeline and in production, and only bring in human experts after you’ve cleaned up all the DAST findings. That way, you’ve got continuous testing coverage and you get better value from pentesting because the experts can work on more advanced vulnerabilities.

Learn how Invicti DAST helped Channel 4 cut pentesting costs by 80% in the first year

DAST is more than a compliance box to tick

Subpar DAST tools confirm all these myths and more, giving proper DAST a bad name. Done right, DAST can serve as a foundational piece of your entire application security program, covering your realistic attack surface while also filling in the gaps left by SAST and penetration testing. And unlike SAST, which is only used in development, it can do double duty in AppSec and InfoSec, serving as the CISO’s gauge for real-life security posture, especially with features like Invicti’s Predictive Risk Scoring.

All that is true only if you pick a serious and comprehensive DAST solution. The compliance checkbox trap lures companies with low-cost or bundled DAST that is only offered to tick a box and doesn’t add much value on top of a vendor’s core products. We’ve got a whole separate post on the dangers of check-the-box DAST, so go check that out. And remember that the main reason for getting any security tool is to get security improvements—merely checking the box won’t do that.