Dynamic Application Security Testing (DAST)

Dynamic application security testing (DAST) finds vulnerabilities in a running application by sending it hostile HTTP requests and inspecting the responses, with no access to source code. DAST is strong at injection and misconfiguration bugs seen from the outside, but it runs after deploy and cannot detect supply chain malware that executes at install time.

Dynamic application security testing (DAST) is a black-box test: the scanner treats the application as an opaque system and probes it from the outside, the way an external attacker would. The OWASP DevSecOps Guideline puts it plainly: DAST is “a ‘Black-Box’ testing, can find security vulnerabilities and weaknesses in a running application.” The scanner needs no source code and no knowledge of the framework underneath.

That outside-in stance is what separates DAST from static application security testing (SAST), which reads the code without ever running it. Both sit under the broader heading of application security testing (AST). DAST trades SAST’s line-level visibility for something SAST cannot have: evidence that a flaw is reachable and exploitable against the deployed configuration, not merely present in a file.

A DAST scan works in three phases against the live application: crawl, passive checks, then active checks. The crawl phase loads the target in an instrumented browser, follows links, submits forms, and maps every reachable request. Passive checks then inspect what the crawl returned: response headers, cookies, a missing Content Security Policy, secrets left in the page.

Active checks are the part most people mean by “DAST.” They inject attack payloads into the requests recorded during the crawl and watch the responses for evidence of success. They are also the part scanners ship switched off. GitLab’s analyzer states it directly: “Active scans are disabled by default because they simulate adversarial behavior.”

The hardest findings to confirm are blind: a payload that triggers no visible change in the response. DAST confirms those two ways. A timing check sends input that makes the server pause, then flags the endpoint if the reply is abnormally slow. GitLab’s timing rule, for example, injects a ten-second sleep and raises a finding when the response takes longer than ten seconds to return.

# Active timing check, as GitLab documents it
payload:     <input that makes the backend wait> sleep 10
baseline:    normal response ~50 ms
flag when:   response time > 10 s   -> input reached the backend

The second method is out-of-band: the payload tells the target to call a server the tester controls, and the callback proves the bug even when the application’s own response reveals nothing. Hold that second idea. Attackers reuse the exact same channel, and we return to it at the end.

DAST is strongest on the injection family. SQL injection and cross-site scripting (XSS) are its textbook targets, and both sit at the top of MITRE’s 2025 CWE Top 25. DAST also catches server misconfiguration, weak authentication handling, and exposed secrets, which is most of the OWASP Top Ten for a running web application.

What DAST misses falls into three groups. It struggles with business-logic abuse that looks legitimate request by request. It can only confirm blind bugs through timing or out-of-band callbacks, and it only tests the paths the crawler actually reaches. And it has no model of your dependencies at all.

That last gap matters most. DAST reads the application’s behavior through the front door, but the code behind that behavior was mostly written by other people and fetched by a package manager minutes before the build. DAST never sees that code, and it never sees the moment it was installed.

DAST, SAST, and SCA answer different questions, and a real program runs all three. The table below is the short version.

Verdict: run SAST on every pull request for first-party code, DAST against staging for anything internet-facing, and software composition analysis (SCA) plus package behavior analysis for the dependency code the other two never execute. Interactive application security testing (IAST) instruments the running app to pair SAST-style locations with DAST-style confirmation, but it only covers the routes your tests exercise. The one false choice is DAST versus SCA: they do not overlap, and skipping either leaves a whole class of risk unexamined.

DAST cannot see the software supply chain because the malicious code runs before DAST ever connects. A supply chain attack does not arrive as a hostile request through the front door. It arrives as a dependency, and it executes at two moments the scanner is not present for.

The first moment is dependency install. npm and pip run install scripts and setup.py as the package lands on disk, on a laptop or a CI runner, long before anything is deployed. npm v12, shipped July 8, 2026, finally turned install scripts off by default, an admission that default-on lifecycle scripts were a design mistake. The second moment is interpreter startup: in the LiteLLM compromise, malicious wheels dropped files that Python runs at startup, so the stealer executed without the application importing anything.

By the time a DAST scan sends its first request, both moments have passed and any secrets in the build environment are already gone. This is why we think the place to stop a malicious package is before install, not after deploy. Socket analyzes what a package actually contains, independent of what its metadata claims, and Socket Firewall puts that verdict in the install path, checking each package before the package manager fetches it. DAST remains the right tool for a zero-day in code you wrote. It is the wrong tool for code the attacker wrote.

Attackers have turned DAST’s own out-of-band infrastructure into an exfiltration channel. Out-of-band application security testing (OAST) is the technique behind DAST’s blind-bug detection: a payload makes the target call a domain the tester controls, such as oastify.com or oast.fun, and the callback proves the vulnerability. The same services move stolen data just as well.

Socket’s research team found malicious packages that weaponized OAST across npm, PyPI, and RubyGems, using those exact endpoints to exfiltrate hostnames, environment variables, and working directories. One npm package, adobe-dcapi-web, faked version numbers from 99.99.95 to 99.99.99 to pose as the newest release, then beaconed to an oastify.com subdomain. Some exfiltration domains in the campaign, such as byted-dast.com, carry “dast” in the name outright: the attacker’s recon channel and the tester’s are the same channel.

That symmetry is the uncomfortable center of this topic. The out-of-band callback that proves a blind bug to a security tester proves a stolen credential to an attacker, and the install script that delivered it ran before any scanner connected. DAST watches the perimeter of a deployed application. A supply chain attack never touches that perimeter. It is already inside, installed with everything else, and it finished its work before the app came up.