What we still need to verify : 2 points in this profile are not yet confirmed against vendor documentation.
- Analyzer implementation has changed over time, confirm which engine and configuration options are current
- Which tier includes which scanning capability: confirm against vendor documentation
Treat these points as unconfirmed. They are open items in the catalog's verification queue, and this note stays until each is checked against the vendor's documentation.
What it does
GitLab DAST is a scanning job you add to a pipeline. It runs as a container in the pipeline, points at a URL, crawls the target with a browser based analyzer so client side navigation is followed, then audits discovered requests with active checks for the common web classes: injection, cross site scripting, header and cookie misconfiguration, transport problems and information disclosure. A separate analyzer handles APIs, driven from an OpenAPI specification, a HAR file or a Postman collection rather than from crawling.
The integration is the point. Findings are emitted in GitLab's report format, which means the merge request shows a security widget listing new vulnerabilities introduced by the branch against the target branch baseline. Approvals can be required when severities cross a threshold, findings can be dismissed with a reason that persists, and confirmed issues can be turned into GitLab issues without leaving the interface. Because GitLab can spin up a review environment per merge request, the scanner can be pointed at a running instance of exactly the code under review.
Where it fits
This runs at merge request and pipeline time, configured by whoever owns the CI definition and consumed by developers in the merge request. It requires a deployed target, so the real prerequisite is a review app or a reliable staging deployment. Full scans are slow, so most teams run a time bounded scan on merge requests and a longer scan on the default branch or on a schedule. It also requires the paid tier that includes security scanning, which makes it a platform decision rather than a tool decision.
Strengths
- Findings appear in the merge request against a baseline, so developers see what their change introduced rather than the whole backlog.
- No additional vendor, contract or console if you already run GitLab.
- Review app integration means scanning the exact code under review, not a shared staging environment that has drifted.
- Separate API analyzer driven from specifications rather than crawling.
Limitations
- Detection depth is behind dedicated commercial scanners. It is convenient first, thorough second.
- Authenticated scanning is configurable but brittle, and complex login flows are a common source of silent coverage loss.
- Scan duration forces a trade off between useful coverage and acceptable pipeline time.
- Tied to GitLab and to the higher tier, so it is not portable if you move platforms.
Who it suits
The obvious choice for teams already on the GitLab tier that includes it, who want a baseline dynamic control without introducing another vendor. Not the right answer if dynamic testing is a primary assurance requirement, if you need deep authenticated coverage of complex applications, or if you are not already committed to GitLab.
Used GitLab DAST? Recommend it under your own name and title.
Recommend this tool