GitLab DAST runs automated penetration style tests against a running web application or API, looking for flaws such as cross-site scripting, SQL injection and cross-site request forgery. It looks at the app from the outside in and is language neutral. It is an Ultimate tier feature.
DAST in one paragraph
Dynamic application security testing sends requests to a deployed app and watches the responses. It does not read your source. That makes it useful for finding what only shows up at runtime, such as a misconfigured header or a flawed login flow, and less useful for pointing at the exact line to fix.
How GitLab runs it
According to the GitLab documentation, the browser based analyzer scans web applications, including single page applications. The older proxy based analyzer was removed in GitLab 17.3, and migration guides exist for DAST version 5. You can run scans in a pipeline, on a schedule or on demand. Each analyzer is configured through a CI template and runs in a Docker container. GitLab compares results between the source and target branches to highlight what a change introduced.
Results appear in the merge request, the pipeline Security tab and the vulnerability report. The merge request shows how many URLs were scanned, and a details link lists them, which is a quick way to check whether the crawler reached the pages you care about.
SAST versus DAST
| Question | SAST | DAST |
|---|---|---|
| Needs a running app? | No | Yes |
| Sees source code? | Yes | No |
| Points to a line of code? | Yes | Usually no |
| Finds runtime and config issues? | Limited | Better suited |
| Language specific? | Yes | No |
They complement each other. A flaw SAST flags in code may or may not be exploitable in the running app, and DAST can confirm it.
Things the page leaves open
The page we reviewed does not describe target requirements or authentication, and points to separate profile pages. Many real applications sit behind a login, so test an authenticated scan early, and use a staging environment, not production, because active tests send hostile looking requests.
It also repeats a caveat from other scanners: if any job in the pipeline fails, the security dashboard does not show DAST output.
A first scan plan
- Pick a staging target with test data and no real customer records.
- Run a baseline scan and open the list of URLs scanned.
- Compare the URL list with your routes. Missing areas mean the crawler did not reach them.
- Add authentication and rerun.
- Triage findings by severity and whether they can be reproduced.
Where a dedicated scanner fits
If you want dynamic testing that starts from the code, or one place for SAST, dependency and DAST results, a separate platform can cover that. Safeguard offers DAST and API scanning alongside SBOM and dependency scanning, with a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch which URLs the scan reaches and which finding types come back.
Quick check
Does DAST need access to my source code?
No. It tests the running application from the outside.
Should I run DAST against production?
Staging is the safer default, because active tests send attack style requests.
Sources
Last reviewed: 19 October 2026.
