Dynamic Application Security Testing (DAST) is a black-box testing method that probes a running application from the outside — sending crafted HTTP requests, malformed inputs, and attack payloads at a live URL — to find vulnerabilities like SQL injection, cross-site scripting (XSS), and broken authentication without ever looking at source code. DAST tools such as OWASP ZAP, Burp Suite, and Invicti crawl an application the way a real attacker would: following links, filling forms, fuzzing parameters, and inspecting responses for signs of a successful exploit. Because it tests the deployed, compiled application rather than static code, DAST catches configuration errors, runtime logic flaws, and issues introduced by the specific server, framework, or third-party service the app actually runs on. It's typically run against staging or pre-production environments in CI/CD, and it maps directly to categories in the OWASP Top 10, the industry's most-cited list of web application risks, last updated in 2021 and due for its next major revision.
How does DAST actually work?
DAST works by treating the target application as a black box: the scanner has no access to source code, and instead interacts with the app purely through its exposed HTTP/HTTPS interface, exactly as an external attacker would. A typical scan runs in two phases. First, a crawler (or "spider") maps the application by following every link, button, and form it can reach, building an inventory of endpoints, parameters, and input fields — this is why authenticated scans, where the tool logs in first, find far more issues than unauthenticated ones, since most business logic sits behind a login wall. Second, the active scan phase injects thousands of attack payloads — things like ' OR 1=1-- for SQL injection or <script>alert(1)</script> for XSS — into every discovered input, then analyzes the HTTP response codes, response bodies, timing, and error messages for evidence the payload succeeded. A tool like OWASP ZAP ships with roughly 100+ built-in active and passive scan rules covering categories from the OWASP Top 10 and CWE database, and a full authenticated scan of a mid-sized app (50-200 endpoints) commonly takes anywhere from 20 minutes to several hours depending on crawl depth and rate limiting.
What's the difference between DAST and SAST?
The core difference is that SAST reads source code without running it, while DAST attacks a running application without reading its code. Static Application Security Testing (SAST) tools like Semgrep, SonarQube, or Checkmarx parse your codebase — Java, Python, Go, whatever — into an abstract syntax tree and flag risky patterns: unsanitized input flowing into a database query, a hardcoded API key, a missing input validation check. SAST can run on day one of a project, before there's anything to deploy, and it can point to the exact file and line number of a flaw. DAST, by contrast, needs a deployed, running instance and can only report the URL and parameter where it observed a problem, not the underlying code path. The two also disagree on false positive rates for different reasons: SAST tends to over-flag because it can't always tell if a "risky" pattern is actually reachable or sanitized elsewhere, while DAST tends to under-report because it only finds what its crawler actually reaches — a vulnerable endpoint behind a form the crawler never fills out simply never gets tested. Most mature AppSec programs run both, since Gartner and OWASP guidance has consistently framed them as complementary rather than substitutes.
What can DAST find that static analysis misses?
DAST finds runtime and environment-specific issues that only exist once code is deployed and configured — things no amount of source code review will surface. Classic examples include server misconfigurations (an exposed .git directory, a debug console left enabled in production, verbose error messages leaking stack traces), broken authentication and session management (session tokens that don't expire, predictable password-reset tokens), and issues that emerge from the interaction of multiple components, like a reverse proxy that mishandles a header in a way that enables request smuggling. The 2017 Equifax breach is a well-documented case in point: the underlying flaw was a known Apache Struts vulnerability (CVE-2017-5638), but the exploitable condition — an internet-facing dispute-portal endpoint running an unpatched Struts version with no WAF rule blocking the payload — was a runtime/deployment fact, exactly the kind of thing an authenticated DAST scan against the live portal would have flagged months before attackers did. DAST also catches TLS/SSL misconfigurations, missing security headers (CSP, HSTS, X-Frame-Options), and CSRF gaps that only manifest in the live HTTP exchange.
What are the limitations of DAST?
DAST's biggest limitation is coverage: it can only test what its crawler can reach and what its scan rules know to look for, so anything behind complex multi-step workflows, CAPTCHAs, or non-standard API formats (gRPC, GraphQL without a schema import, WebSockets) is frequently missed entirely. A 2021 OWASP survey of scanner effectiveness found wide variance in detection rates across tools for the same benchmark application (OWASP's own Benchmark project), with some scanners catching under 30% of seeded vulnerabilities in certain categories like SSRF and XXE. Speed is a second constraint: a thorough authenticated scan of a large application can take hours, which doesn't fit cleanly into a CI pipeline that developers expect to complete in minutes — teams often end up running DAST nightly or weekly rather than on every pull request, meaning a vulnerable code change can sit in production for days before a scan catches it. Third, DAST produces no code-level context: a finding says "SQL injection at /api/v2/orders?id=" but not which commit introduced it or which line to fix, so triage still requires a human to trace the finding back to source, which slows remediation.
When should DAST run in the SDLC, and how often?
DAST should run against every build promoted to a staging or pre-production environment, not just before a major release, because vulnerabilities can be introduced by any dependency bump, config change, or infrastructure update, not only new feature code. In practice this means most CI/CD-integrated DAST setups trigger on merge to a staging branch or on a nightly cadence against a persistent staging deployment, since full active scans are usually too slow to gate every commit. Lighter-weight passive scanning — where the tool observes traffic from existing functional or E2E tests rather than actively crawling and fuzzing — can run on every build in under a few minutes and catch missing security headers or exposed error details without the time cost of a full active scan. PCI DSS 4.0, in effect since March 2024, explicitly requires regular vulnerability scanning of public-facing web applications (Requirement 6.4.2), and many compliance frameworks treat DAST or an equivalent WAF-based control as satisfying that requirement, which is why regulated fintech and healthcare teams often run full DAST scans at minimum quarterly, on top of continuous lighter checks.
Is DAST alone enough for application security?
No — DAST alone leaves significant gaps that require SAST, software composition analysis (SCA), and cloud/infrastructure scanning to close. DAST doesn't see third-party and open-source dependency vulnerabilities the way SCA tools do (it might detect a Log4j-powered endpoint behaving oddly under a crafted JNDI payload, but it won't tell you it's specifically CVE-2021-44228, a.k.a. Log4Shell, or which of your 40 microservices carry the vulnerable library version). It also can't see infrastructure-as-code misconfigurations, secrets committed to a private repo, or container image vulnerabilities that never manifest in an HTTP response. This is why the CISA and NSA's 2023 joint guidance on secure software development recommends layered testing — combining static, dynamic, and composition analysis — rather than relying on any single method, and it's the same reasoning behind the shift many AppSec teams are making toward unified platforms that correlate findings across all these tools instead of running them as disconnected point solutions with separate dashboards and separate backlogs.
How Safeguard Helps
Safeguard complements DAST findings with reachability analysis, tracing whether a dynamically-discovered vulnerable endpoint actually connects back to exploitable code paths and vulnerable dependencies, so teams stop triaging DAST alerts that sound scary but are functionally dead ends. Griffin AI, Safeguard's reasoning engine, correlates DAST scan output with SAST, SCA, and SBOM data to explain in plain language why a given finding matters, what data or systems it touches, and how urgently it needs attention — closing the code-context gap that standalone DAST tools leave open. Safeguard generates and ingests SBOMs automatically so the components behind every scanned endpoint are already inventoried before a DAST scan even runs, and when a fix is identified, Safeguard can open an auto-fix pull request with the patched dependency or configuration change ready for review, cutting the time between "scanner found it" and "code is merged" from days to minutes.