GitLab DAST browser-based scanning setup

When GitLab DAST with the browser-based analyzer fits your release process

The browser-based DAST analyzer runs dynamic application security testing against a web application that is already running, so it exercises the app the way a user or attacker would reach it through a browser. Teams need it when they ship web apps or single-page applications from a self-managed GitLab and want the same dynamic checks to run on every release, on a schedule, or on demand, rather than relying on occasional manual testing. Static analysis reads source code and cannot see how the deployed front end, its APIs and its authentication behave at runtime, which is the gap DAST is meant to close. In GitLab, DAST is an Ultimate capability, so the first decision is whether your edition covers it. Confirm the current tier mapping on the GitLab pricing page before you plan around it.

Fit depends on your release process more than on the tool. If your pipeline already deploys to a review or staging environment that is reachable from the runner, a DAST job can target that environment after deployment and report findings into merge requests and the vulnerability report. If your app needs logins, multi-step flows or a single-page front end that builds its views in JavaScript, plan for authentication setup and confirm how the analyzer handles those flows in the current GitLab DAST documentation. Ask your team which environments can safely receive active attack traffic, who owns them, and whether they hold production data. Those answers decide whether the analyzer runs against staging, a dedicated test copy, or on a schedule outside release windows.

Plan DAST as a control that runs alongside your other testing, not as a replacement for it. A DAST scan reports what the analyzer can observe from outside the application, within the scope and authentication you configure, and it does not establish that an application is secure. A manual penetration test brings a tester who chases business logic, chains weaknesses and adapts to what they find, and it produces a scoped report with a defined engagement. Decide which findings your release gates will block on, who triages the results, and how often you need a human test in addition to the pipeline. Confirm the analyzer's current capabilities and supported configuration options in the GitLab docs before writing those rules into policy.

Choosing between pipeline, scheduled and on-demand DAST runs

Running DAST in merge request or branch pipelines puts a dynamic scan next to the code change that might have caused a finding. The scan runs against a review environment deployed from the branch, so a reviewer can connect a new finding to the change that introduced it. The cost is time and noise: a full crawl and active checks can add significant minutes to every pipeline, and a freshly deployed review environment is often less stable than a long-running one.

Scan time: Each merge request pays the full duration of the scan, so teams usually limit this job to a passive or short crawl and reserve deeper active scans for other runs.
Target stability: Review environments may still be warming up, seeded with partial data or restarting, which produces false errors and missed pages.
Noise in merge requests: Findings from unrelated code can appear on a change that did not touch them, so set policies to report new findings instead of blocking on the full backlog.
Reviewer visibility: Results appear in the merge request security widget, which keeps the feedback close to the author and the reviewer.
Credentials: Review environments need test accounts and CI variables that are scoped to them and rotated.

Before adopting this model, confirm with your platform team how review environments are provisioned, how long they take to become healthy, and whether the scan can wait for readiness.

Configuration options for the browser-based DAST analyzer

This table compares the main configuration choices for a browser-based DAST run, with when each option fits and what it risks. Read each row as a decision: pick the target type, authentication approach, scope and check mode that match your environment, then confirm the exact variable names and defaults in the current GitLab DAST documentation before you rely on them.

Option	When it fits	Risk to plan for
Target URL	A stable staging or test site with a fixed address that the pipeline can reach on every run.	Scans may hit a shared environment that other teams use, so confirm who owns it and when scans are allowed.
Target from an environment or review app	Scans that should follow each deployment, such as a review app created by a merge request pipeline.	The target URL changes per run, so the job must wait for the deployment and pass the correct address reliably.
Authenticated scanning for logged-in areas	Applications where most functionality sits behind a login, so an unauthenticated scan would miss it.	Scan credentials need careful handling in CI/CD variables, and a session that expires or a changed login flow can silently reduce coverage.
Dedicated scan account	Applications with role-based access, where the scan should exercise a standard user rather than an administrator.	Test data created by scans can accumulate, so confirm the account can only reach non-production data.
Scope and exclusions	Large applications where logout, delete, or payment endpoints must be skipped or where third-party domains should not be crawled.	Overly broad exclusions leave parts of the app untested, while missing exclusions can trigger destructive actions.
Passive checks only	Production-adjacent or sensitive environments where the owner has not approved active attack traffic.	Passive checks find fewer issues, so reviewers should not read a clean run as proof that active flaws are absent.
Active checks	Dedicated test environments that the owner has approved for attack-style requests against the application.	Active checks send malicious-looking input, which can fill logs, change data or trip rate limits and alerts.
Results stored as pipeline artifacts and the Vulnerability Report	Teams that want findings tracked, triaged and linked to merge requests, with reports kept for review.	Findings need an owner and a triage process, or the report becomes a backlog nobody reads. Confirm which tier provides the vulnerability management features you need.
Scheduled or on-demand runs	Regular checks of a stable environment, or ad hoc scans after a significant change or a reported issue.	Scheduled runs on an unchanged target add little; pair them with pipeline runs after each deployment.

How to set up DAST in a self-managed GitLab pipeline

This sequence takes DAST from licensing and runner checks through a dedicated test target, pipeline configuration, authenticated scanning and a baseline run, ending with findings reviewed by the security team. Each step closes with a check so you know it worked before moving on.

Confirm the Ultimate license and runner capacity
The platform owner confirms that the self-managed instance holds a license for the Ultimate tier, since DAST is an Ultimate feature according to GitLab's pricing page, and that the project has access to a GitLab Runner able to run the DAST job. Check the runner's executor and whether it can reach the target network, because a scan that cannot reach the application will fail or report nothing useful. Ask the runner administrator to confirm the runner tags you will use in the job. You are done when a test job on that runner completes and the license shows the Ultimate features enabled in the instance administration area.
Provision a dedicated non-production target
Stand up a staging or test copy of the web application that the security team has agreed to scan, with test data only and no connections to live payment, customer or production identity systems. Scanning actively sends requests that can create records, trigger emails or change state, so the target should be isolated and restorable. Record the base URL and the network path the runner uses to reach it. Confirm that the application is reachable from the runner with a simple HTTP request from the same network segment, and that the owner accepts that the scan may alter test data.
Add the DAST template to the pipeline
The developer or pipeline engineer includes GitLab's DAST template in .gitlab-ci.yml and sets the target with the DAST_WEBSITE variable, adding a stage that runs after the application is deployed to the test environment. Set the scan to run from a pipeline, a schedule or on demand, depending on the team's policy, and keep the job's allowed targets limited to the approved host. Confirm the YAML passes pipeline linting in the project's CI/CD editor. You are done when a pipeline run starts the DAST job and the job log shows the analyzer requesting the configured URL.
Configure authentication for protected pages
Most business applications only expose meaningful functionality after login, so a scan without credentials tests only the public surface. The application team works with the security team to choose a test account with the least privilege needed, then stores its credentials as masked and protected CI/CD variables rather than in the repository. Review the authentication options in the DAST documentation for your application's login flow, and confirm with the security team how multi-factor prompts or single sign-on redirects will be handled in the test environment. You are done when a test run logs in successfully and the job log shows requests made to pages that require a session.
Run a baseline scan
Run a baseline scan first, which is the lighter passive check, to establish what the analyzer finds on the target before running any more active testing. The security team reviews the job output and confirms the spider covered the expected pages, using the job log and the number of URLs crawled as the indicator. Keep the scan window and the target agreed in writing so that the test environment owner knows when activity will happen. You are done when the job completes without errors and its artifacts, including the report, are attached to the pipeline.
Confirm results reach the vulnerability report
Check that the DAST job publishes its findings as a report artifact that GitLab ingests into the project's vulnerability report, which is where triage, status changes and linking to issues happen. Ask the security team to open a sample of findings and confirm each one contains the affected URL, the request and response evidence, and a severity they can act on. Mark findings that are false positives, record the reason, and agree on who owns triage and how often it happens. You are done when the security team has triaged the baseline findings and has a recorded owner for each open item.
Review findings with the security team
Hold a review between the application owners and the security team to decide which findings need remediation, which need more evidence, and which are accepted risks with a documented reason. Confirm which scan types, such as a full active scan, the team will run later and under what conditions, since that decision affects target load and data impact. Document the agreed scan profile, target, credentials handling and triage owner in the project's runbook. You are done when the decisions are recorded and the next scheduled scan is set up with the agreed settings.

How to choose a safe DAST target

Choose a DAST target that you own and can afford to break before you point an active scan at anything. The browser-based analyzer does more than read pages: it crawls the application, submits forms, follows links and sends attack payloads, so a scan against production can create orders, send emails, lock out users or flood a fragile backend. Production is a poor default for active checks. Where production must be tested, limit the scan to passive or read-only coverage and get the owners' written agreement first. Confirm in the current DAST documentation which scan modes and options the analyzer exposes in your version so the scope you approve matches what actually runs.

Ephemeral review apps are the safest first target when your deployment process can create one per merge request. The application and its database are created for the pipeline run, seeded with synthetic data and destroyed afterward, so a destructive payload only harms data nobody needs. Staging copies are the next option. Use a copy refreshed from production only after personal data and secrets are masked or replaced, and confirm that the copy has no live integrations to payment, messaging or email providers. Whatever the target, the analyzer should authenticate as a dedicated test account with the narrowest role that still reaches the pages you want covered, and that account should not be able to approve, delete or transfer shared records. Ask your team which accounts exist on the target and who can reset them.

Shared dependencies decide the rest. Rate-limit the scan so that it does not exhaust connection pools, trip upstream API quotas or fill queues that real users depend on, and confirm the request rate with the owners of identity providers, payment gateways and third-party APIs your application calls. Agree a scan window with those owners, record it in the pipeline schedule and make sure someone can stop a running job. Treat each scan target as a change to your environment: document what it touches, who approved it and what evidence the scan leaves behind, because that record is what a reviewer or auditor will ask for when a finding is disputed.

Security and operational risks of running DAST

A DAST job sends live attack traffic at a running application, so the risks sit in where it points, what credentials it holds, what it can reach and what its output contains. Each card names the control to apply before a scan runs against anything you care about.

Active attacks against the wrong host

DAST in active mode sends attack payloads, not just requests, so a mistyped target URL can hit a system nobody meant to test. Pin the target in the pipeline configuration, keep it in a protected variable that only maintainers can change, and confirm the host resolves to the staging environment before the first run. Treat any production target as a separate, approved decision with its own change record.

Test account credentials in CI variables

Authenticated scans need a login, and the usual shortcut is a username and password stored as CI/CD variables. Create a dedicated test account with the minimum role the scan needs, mark the variables as masked and protected, and rotate the password on a schedule. Confirm that the account cannot reach real customer data, since anyone who can read job logs or change pipeline configuration can reach the scanned application as that user.

Scan traffic triggering alerts or outages

A browser-based crawl generates many requests in a short window, which can trip rate limits, fill logs, page on-call staff or degrade a shared test database. Agree the scan window with the application owner, set a crawl scope that excludes destructive pages such as delete or reset actions, and check that the target can absorb the load. Ask the owners of any WAF or intrusion detection in front of the target to allow-list the runner's address for the duration of the scan.

Findings containing sensitive data

DAST reports include captured requests, responses and sometimes page content, which can contain session tokens, personal data or internal hostnames. Decide who may view DAST results in the project, restrict artifact retention to the period your review cycle needs, and check the report output after the first run on a realistic test dataset. Findings that reach issue trackers or chat channels copy that data outward, so set the integration scope before enabling it.

Runners with network reach into production

A runner that executes DAST jobs sits on whatever network it is attached to, so a runner placed in a flat network can reach databases, admin consoles and internal APIs that the scan never needs. Run DAST jobs on dedicated runners in a segment that can reach only the test target, and use a runner tag that only the scan job requests. Review the egress rules of that segment with the network team, because they decide what an attacker who compromises a job could also reach.

Drift between scanned and deployed builds

A DAST pass against last week's build says little about what is running now, and findings may point at code that has already changed. Tie each scan to the image or artifact digest the pipeline deployed to the target, record that digest in the scan results, and run the scan after the deployment job completes rather than in parallel with it. When the deployed version and the scanned version differ, mark the result as stale rather than treating it as current evidence.

What to confirm about DAST limits in your environment

DAST results only reflect what the scanner could reach and log into during a run. The cards below cover the items to verify in your own instance and application before you treat a clean report as coverage. Each one can silently narrow what gets tested.

Ultimate licensing for the instance

DAST is an Ultimate feature, and the pillar's pricing facts list application security testing as Ultimate-only, with Ultimate custom priced. Confirm that the self-managed instance and the projects that run the scan hold an Ultimate license before the first pipeline. A DAST job on a non-Ultimate instance does not give you the coverage the job name suggests, so confirm the license with your GitLab account contact rather than from the job log.

Authentication flows and SSO-protected apps

A scanner that cannot pass your login flow only tests the sign-in page. Check whether your application uses SSO, multi-step MFA, CAPTCHA or short-lived tokens, and whether the browser-based analyzer can complete that flow with a dedicated test account. Confirm this with a test run against a staging copy, and check the logged-in pages appear in the results.

Single-page app routing

Single-page applications load most views through client-side routing, so a crawler that follows only server-rendered links may miss large parts of the app. Ask the team which routes, deep links and modal flows exist, and compare the scanner's discovered URLs against that list. Gaps here usually mean the scan covered the shell of the app and little else.

API-only and mixed targets

The browser-based analyzer is aimed at web applications that a browser can drive. A backend that exposes only JSON or GraphQL endpoints, with no UI to crawl, needs a different approach or an API-focused test. Confirm whether the API surface in scope can be reached and described to the scanner, and plan a separate API test where it cannot.

Offline and air-gapped analyzer availability

In a disconnected network, the analyzer images and their dependencies must be mirrored into your registry before a job can run. The pillar's offline facts say GitLab documents separate guidance for running its security scanners offline, so read that guidance and confirm that every analyzer image the DAST job pulls is available inside your boundary. Ask who owns the mirror and how often it is refreshed.

Application types in scope

Map each application in scope to its architecture, including legacy server-rendered pages, SPAs, file upload flows, WebSocket features and third-party embedded widgets. Confirm for each one whether the browser-based analyzer exercises the functionality that carries your risk. A clean result on a login page does not show that a payment or upload path was tested.

Safe target and environment selection

Active scanning sends real requests that can change data, trigger workflows or load a system. Confirm that the target is a non-production copy with test data, that scan traffic is allowed through your WAF and rate limits, and that someone owns the scan window. Writing this down is part of the change record for the pipeline.

How DAST in Ultimate differs from a manual penetration test

DAST and a manual penetration test answer different questions, so they should not be scored against each other. The GitLab DAST analyzer, configured in a pipeline with the browser-based analyzer, is automated and repeatable: it runs the same crawl and checks against a target on each change, on a schedule, or on demand, and it reports findings in the pipeline and in the vulnerability report. Ultimate is the tier that provides DAST, so confirm that your license covers it before you plan the program around it. A manual penetration test, by contrast, depends on a tester's judgment. A tester chains small weaknesses into an impact, abuses business logic such as approval flows, pricing, or tenant boundaries, and follows leads that no scanner rule anticipates. That work needs a defined scope, rules of engagement, agreed testing windows, and a written report with evidence and remediation advice.

DAST complements a penetration test and does not replace one. Use the scanner to catch regressions continuously, especially for the common web flaws that a crawler can reach, and use a human test to probe authentication design, authorization logic and multi-step abuse. Plan the scan targets, authentication settings and exclusions with the same care you give the penetration test scope, and record which findings were triaged as false positives and why. Confirm with your assessor which evidence they expect, such as scan configuration, schedules, triage records and penetration test reports, because an auditor evaluates whether your security testing program is designed and operated consistently. The tool output is one input to that judgment, not the judgment itself.

Questions buyers ask about GitLab DAST setup and cost

What drives the cost of running GitLab DAST compared with a consultant-run setup?

Two separate costs are involved. The first is the GitLab license: DAST is part of the Ultimate tier, which GitLab prices as a custom quote, and the GitLab pricing page lists application security testing among Ultimate features. The second is the labor to configure and maintain scans, which is what a partner or your own engineers are paid for. Labor scales with the number of applications, how hard authentication is, how many environments need scanning, and how much pipeline work is involved. Ask any partner for a fixed-scope written quote that separates labor from licensing, and ask your GitLab account team for an Ultimate quote based on your user count and feature needs.

How long does a GitLab DAST setup take, and what makes it longer?

Duration depends mostly on target readiness, not on the scanner itself. A stable, non-production test environment with seeded data and a known list of routes moves quickly. Authentication is the most common delay: a login flow that uses multi-factor prompts, single sign-on redirects or CAPTCHAs needs extra configuration and testing before scans return useful coverage. Pipeline changes, approval steps and the number of applications also add time. Ask for a timeline tied to a written scope, and confirm which of these items your environment already has in place before it is agreed.

What does the work need from our team?

Plan for three groups of people. A test environment owner must provide a non-production copy of the application that can be scanned without affecting real customers. Test account owners must create dedicated low-privilege and, where needed, higher-privilege accounts that are not shared with people. Pipeline owners must agree where DAST jobs run, who approves changes to the CI/CD configuration and who reviews findings. Each group needs a named contact and time in the schedule. Without these owners, setup usually stalls at the point where a scan needs credentials or a stable target.

Can our own team set up GitLab DAST without outside help?

Yes, if your team already runs GitLab CI/CD, can manage a test environment and has someone comfortable with web authentication flows. The GitLab documentation covers the DAST job configuration, and the browser-based analyzer is configured through the pipeline. The points that typically need experience are authentication scripting, choosing scan scope so that the crawler does not leave the test target, and tuning findings so that developers act on real issues. Teams without that experience often spend the most time on the first application. A useful test is whether one engineer can get an authenticated scan of a single application running on a schedule, with reviewed results, within your own change process.

How does DAST fit into a fixed-scope engagement with DeployOpen?

DeployOpen agrees the scope, deliverables and timeline in writing before work starts, and most engagements are fixed-scope. For GitLab DAST, a written scope typically names the applications to scan, the environments, the authentication method, the pipeline changes, the findings workflow and the handover documentation. Ongoing scanning, tuning and updates can be covered by a retainer. DeployOpen configures and documents the setup; it does not issue audit reports or certifications. Ask for the written scope to list what is excluded, such as application code fixes or Ultimate licensing, so both sides know who owns each item.

Is GitLab DAST the same as a manual penetration test?

No. DAST is an automated scanner that sends requests to a running application and reports responses that match known vulnerability patterns. It runs repeatably from a pipeline and is good at catching common issues across many routes. A manual penetration test is performed by a tester who chains weaknesses, reasons about business logic and tries attack paths a scanner does not model. Many teams use both: DAST for continuous coverage and penetration testing for depth and assurance. Neither replaces the other, and DAST results do not by themselves satisfy an independent assessment requirement.

What are the risks of pointing a DAST scan at a live application?

Active scans send attack-style requests, which can create data changes, trigger notifications, lock accounts, fill queues or cause outages on fragile systems. The safe pattern is a dedicated test environment with disposable data, test accounts with no access to real customer records, and a scan allowlist that limits the crawler to known hosts. Schedule scans in a window agreed with the application owner, and make sure the production security team knows the source addresses. Confirm with your GitLab administrator which scan types are permitted in each project before any job runs against a shared target.

How DeployOpen scopes and supports GitLab DAST

DeployOpen plans, configures and documents GitLab DAST with the browser-based analyzer inside your own infrastructure, on a target you have approved for testing. We treat the target list, authentication and scan policy as the main design decisions, then hand over pipeline configuration your team can run and maintain.

How we scope

Inventory the web applications and SPAs you want scanned, and record which environments are safe to test.
Agree in writing which pipelines, schedules or on-demand runs are in scope and who approves each target.
Define the authentication method the scanner must use, including how test accounts are created and rotated.
Confirm your GitLab tier and whether DAST results will feed merge request approval policies.

How we build

Configure the browser-based DAST job in a dedicated CI/CD template, pinned to the analyzer version your instance supports.
Set scan targets, authentication settings and exclusions in version-controlled configuration rather than in the UI.
Run the first scans against a staging target and review findings for noise, false positives and unreachable pages.
Document runner placement, network routes and any offline analyzer images needed for air-gapped environments.

How we hand over

Deliver the pipeline configuration, scan policy and runbook covering targets, credentials and exclusion decisions.
Walk your security and platform engineers through triage of DAST findings and how they map to vulnerability management.
Provide a written list of open items, such as scan load limits, test data cleanup and planned analyzer upgrades.
Document how DAST differs from a manual penetration test so reviewers know which assurance each provides.

How we support

Ongoing support, analyzer upgrades and continuous testing are available as a retainer, scoped separately from the build.
Retainers can cover reviewing new applications before they are added to scheduled scans.
Confirm with DeployOpen, in the quote, who maintains credentials for test accounts after handover.
Ask for a clear boundary between DAST, penetration testing and compliance evidence before work starts.

GitLab DAST with the browser-based analyzer