Dynamic Application Security Testing (DAST) is a black-box testing method that probes a running web application or API the same way an attacker would — sending crafted HTTP requests and inspecting the responses for signs of vulnerabilities like SQL injection, cross-site scripting (XSS), and broken authentication. Unlike static analysis, DAST doesn't need source code, a build pipeline, or compiled artifacts; it needs a URL, a set of authenticated sessions, and a crawler. Tools like OWASP ZAP, first released in 2010 and now maintained by the OWASP Foundation, and PortSwigger's Burp Suite have made DAST a standard line item in AppSec programs for close to two decades. PCI DSS 4.0's Requirement 6.4.2, which took effect March 31, 2025, effectively mandates continuous automated testing of public-facing web applications for any organization that handles payment card data. This glossary entry explains how DAST actually works, what it catches and misses, and how it fits alongside SAST, SCA, and reachability analysis in a modern application security program.
What Is Dynamic Application Security Testing and How Does It Work?
DAST works in two phases: it first crawls an application to map every reachable endpoint, form, and parameter, then it actively attacks each one with payloads designed to trigger observable failures. A typical crawl phase walks the DOM, follows links, and submits forms with placeholder data to build a site map — for a mid-sized application with a few hundred endpoints, this discovery pass commonly takes 30 minutes to a few hours depending on JavaScript rendering complexity. The active scan phase then fires thousands of payloads at each parameter: strings like ' OR '1'='1 to test for SQL injection, <script>alert(1)</script> to test for reflected XSS, and directory-traversal strings like ../../etc/passwd to test for path disclosure. OWASP ZAP's default active scan policy runs more than 60 individual scan rules covering categories from the OWASP Top 10; Burp Suite Enterprise and commercial tools like Invicti and Acunetix run comparable rule sets with added authentication-flow handling and API schema import (OpenAPI/Swagger, GraphQL introspection). The scanner never reads a line of source code — it only judges behavior it can observe over HTTP.
How Is DAST Different from SAST and SCA?
DAST tests a running application from the outside without any visibility into source code, while SAST parses source or bytecode directly and SCA scans dependency manifests and lockfiles for known-vulnerable library versions. The distinction matters because each method catches a different failure mode. Log4Shell (CVE-2021-44228), disclosed on December 9, 2021, is a useful illustration: SCA tools flagged it almost immediately by matching the log4j-core version string in a pom.xml or build.gradle file, no execution required. A DAST scanner would only have caught it if a scan happened to send a JNDI-triggering payload to a parameter that reached the vulnerable log4j logging call at runtime — plausible, but not guaranteed, since DAST is limited to whatever inputs its crawler actually discovers and exercises. SAST, by contrast, would flag the vulnerable logging pattern by reading the code path statically, whether or not that code path is ever invoked during a scan. Mature AppSec programs run all three — DAST, SAST, and SCA — because they cover distinct blind spots rather than overlapping coverage.
What Vulnerabilities Does DAST Catch Best?
DAST is best at finding runtime-only issues that never show up in a code diff: authentication and session-management flaws, server and TLS misconfiguration, and vulnerabilities in third-party or legacy components where no source is available at all. Because it observes the actual HTTP response — headers, status codes, timing, error messages — DAST reliably flags issues like missing Strict-Transport-Security headers, verbose stack traces leaking framework versions, session tokens that don't rotate after login, and reflected XSS that only manifests after the browser renders untrusted input. These map directly onto OWASP Top 10 2021 categories A05 (Security Misconfiguration) and A07 (Identification and Authentication Failures). DAST is also the only practical method for testing compiled binaries, third-party SaaS integrations, or vendor-hosted components where source code was never delivered — you can point a scanner at the login page of a COTS product you don't own the code for, but you can't run SAST against it.
What Are DAST's Blind Spots?
DAST cannot report on code paths its crawler never reaches, which means logic hidden behind multi-step workflows, feature flags, or complex state machines routinely goes untested. A scanner that can't complete a multi-factor login flow, for example, will never test anything behind that wall — including the admin panel that matters most. DAST also produces a meaningful false-positive rate on blind injection and timing-based checks (commonly cited in the 10-20% range for active-scan findings before triage), it requires a live, stateful environment that mirrors production closely enough to be meaningful, and full authenticated scans of a moderately sized application typically take 4-12 hours, which is too slow to run on every pull request. Because it tests from outside, DAST also can't tell you which line of code is responsible for a finding — a developer still has to trace the vulnerable parameter back to source, which is where reachability analysis and SAST correlation add the missing context.
Is DAST Required for Compliance?
Yes — PCI DSS 4.0 Requirement 6.4.2, effective March 31, 2025, requires organizations that handle cardholder data to deploy an automated technical solution that continually detects and prevents web-based attacks against public-facing applications, replacing the older Requirement 6.6 option of a once-every-six-months manual review. In practice, assessors accept a properly configured DAST program (or a WAF with equivalent detection) as satisfying this control, but a one-time annual scan no longer clears the bar — the requirement is written around continuous, automated coverage. SOC 2 doesn't name DAST specifically, but auditors evaluating the Security and Availability trust service criteria routinely ask for evidence of regular web-application testing as part of the vulnerability management control, and a documented DAST scan history with remediation timestamps is one of the most common artifacts submitted. HIPAA and FedRAMP assessments carry similar expectations without naming a specific tool category.
How Do Teams Run DAST Without Slowing Down Releases?
Teams keep DAST out of the release-blocking path by running full scans against ephemeral staging environments on a schedule — nightly or per-merge-to-main — rather than gating every pull request on a multi-hour scan. A common pattern is a lightweight "baseline" scan (crawl plus a subset of low-risk active rules) on every PR, completing in under 10 minutes, paired with a full authenticated deep scan against a staging deployment once a day or once a release cycle. Findings above a defined severity threshold — typically critical and high per CVSS — get filed as tickets or PR comments automatically rather than failing the build outright, since DAST's false-positive rate makes hard blocking on every finding impractical. API-first teams increasingly point DAST scanners at an OpenAPI or GraphQL schema instead of relying purely on crawling, which improves endpoint coverage on services with no browsable UI.
How Safeguard Helps
Safeguard closes the gap between "DAST found something" and "a developer knows exactly what to do with it." Reachability analysis correlates DAST and SAST findings against actual call paths in your code, so a reflected-XSS or injection finding is tied to the specific function and commit that introduced it rather than a bare URL and parameter name. Griffin AI triages incoming findings against your SBOM and codebase context to cut through the false-positive noise DAST is known for, prioritizing the handful of results that are actually exploitable in your environment. Safeguard's SBOM generation and ingest give security teams a live inventory to cross-reference against DAST-discovered components, catching cases — like third-party libraries — that a crawler alone would miss. When a finding is confirmed, Safeguard can open an auto-fix pull request directly against the vulnerable code path, turning a scan result into a reviewable code change instead of another backlog ticket.