A comprehensive guide to GitLab DAST

Modern businesses entirely depend on web-based platforms for customer interactions, financial transactions, data processing, and core business operations. As digital transformation accelerates and remote or hybrid work becomes the norm, the attack surface for web applications has expanded dramatically, making them prime targets for cybercriminals. Therefore, securing web applications has become more critical than ever.

While static code analysis catches vulnerabilities in source code, it cannot identify runtime security issues that emerge when applications interact with real-world environments, third-party services, and complex user workflows. This is where Dynamic Application Security Testing (DAST) becomes invaluable. GitLab's integrated DAST solution provides teams with automated security testing capabilities directly within their CI/CD pipelines, on a schedule, or on-demand, enabling continuous security validation without disrupting development workflows.

Why DAST?

DAST should be implemented because it provides critical runtime security validation by testing applications in their actual operating environment, identifying vulnerabilities that static analysis cannot detect. Additionally, GitLab DAST can be seamlessly integrated into shift-left security workflows, and can enhance compliance assurance along with risk management.

Runtime vulnerability detection

DAST excels at identifying security vulnerabilities that only manifest when applications are running. Unlike static analysis tools that examine code at rest, DAST scanners interact with live applications as an external attacker would, uncovering issues such as:

• Authentication and session management flaws that could allow unauthorized access
• Input validation vulnerabilities, including SQL injection, cross-site scripting (XSS), and command injection
• Configuration weaknesses in web servers, databases, and application frameworks
• Business logic flaws that emerge from complex user interactions
• API security issues, including improper authentication, authorization, and data exposure

DAST complements other security testing approaches to provide comprehensive application security coverage. When combined with Static Application Security Testing (SAST), Software Composition Analysis (SCA), manual penetration testing, and many other scanner types, DAST fills critical gaps in security validation:

• Black-box testing perspective that mimics real-world attack scenarios
• Environment-specific testing that validates security in actual deployment configurations
• Third-party component testing, including APIs, libraries, and external services
• Configuration validation across the entire application stack

Seamless shift-left security integration

GitLab DAST seamlessly integrates into existing CI/CD pipelines, enabling teams to identify security issues early in the development lifecycle. This shift-left approach provides several key benefits:

• Cost reduction — Fixing vulnerabilities during development is significantly less expensive than addressing them in production. Studies show that remediation costs can be 10 to 100 times higher in production environments.
• Faster time-to-market — Automated security testing eliminates bottlenecks caused by manual security reviews, allowing teams to maintain rapid deployment schedules while ensuring security standards.
• Developer empowerment — By providing immediate feedback on security issues, DAST helps developers build security awareness and improve their coding practices over time.

Compliance and risk management

Many regulatory frameworks and industry standards require regular security testing of web applications. DAST helps organizations meet compliance requirements for standards such as:

• PCI DSS for applications handling payment card data
• SOC 2 security controls for service organizations
• ISO 27001 information security management requirements

The automated nature of GitLab DAST ensures consistent, repeatable security testing that auditors can rely on, while detailed reporting provides the documentation needed for compliance validation.

Implementing DAST

Before implementing GitLab DAST, ensure your environment meets the following requirements:

• GitLab version and Ultimate subscription — DAST is available in GitLab Ultimate and requires GitLab 13.4 or later for full functionality; however, the latest version is recommended.
• Application accessibility — Your application must be accessible via HTTP/HTTPS with a publicly reachable URL or accessible within your GitLab Runner's network.
• Authentication setup — If your application requires authentication, prepare test credentials or configure authentication bypass mechanisms for security testing.

Basic implementation

The simplest way to add DAST to your pipeline is by including the DAST template in your .gitlab-ci.yml file and providing a website to scan:

include:
  - template: DAST.gitlab-ci.yml

variables:
  DAST_WEBSITE: "https://your-application.example.com"

This basic configuration will:

• Run a DAST scan against your specified website
• Generate a security report in GitLab's security dashboard
• Fail the pipeline if high-severity vulnerabilities are detected
• Store scan results as pipeline artifacts

However, it is suggested to gain the full benefit of CI/CD, you can first deploy the application and set DAST to run only after an application has been deployed. The application URL can be dynamically created and the DAST job can be configured fully with GitLab Job syntax.

stages:
  - build
  - deploy
  - dast

include:
  - template: Security/DAST.gitlab-ci.yml

# Builds and pushes application to GitLab's built-in container registry
build:
  stage: build
  variables:
    IMAGE: $CI_REGISTRY_IMAGE/$CI_COMMIT_REF_SLUG:$CI_COMMIT_SHA
  before_script:
    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
  script:
    - docker build -t $IMAGE .
    - docker push $IMAGE

# Deploys application to your suggested target, setsup the dast site dynamically, requires build to complete
deploy:
  stage: deploy
  script:
    - echo "DAST_WEBSITE=http://your-application.example.com" >> deploy.env
    - echo "Perform deployment here"
  environment:
    name: $DEPLOY_NAME
    url: http://your-application.example.com
  artifacts:
    reports:
      dotenv: deploy.env
  dependencies:
    - build

# Configures DAST to run a an active scan on non-main branches, and a passive scan on the main branches and requires a deployment to complete before it is run
dast:
  stage: dast
  rules:
    - if: $CI_COMMIT_REF_NAME == $CI_DEFAULT_BRANCH
      variables:
        DAST_FULL_SCAN: "false"
    - if: $CI_COMMIT_REF_NAME != $CI_DEFAULT_BRANCH
      variables:
        DAST_FULL_SCAN: "true"
  dependencies:
    - deploy

You can learn from an example by seeing the Tanuki Shop demo application, which generates the following pipeline:

Understanding passive vs. active scans

In the example above we enabled active scanning for non-default branches:

- if: $CI_COMMIT_REF_NAME != $CI_DEFAULT_BRANCH
  variables:
    DAST_FULL_SCAN: "true"

GitLab DAST employs two distinct scanning methodologies (passive and active), each serving different security testing needs.

Passive scans analyze application responses without sending potentially harmful requests. This approach:

• Examines HTTP headers, cookies, and response content for security misconfigurations
• Identifies information disclosure vulnerabilities like exposed server versions or stack traces
• Detects missing security headers (CSP, HSTS, X-Frame-options)
• Analyzes SSL/TLS configuration and certificate issues
• Is safe for production environments as it doesn't attempt to exploit vulnerabilities

Active scans send crafted requests designed to trigger vulnerabilities. This approach:

• Tests for injection vulnerabilities (SQL injection, XSS, command injection)
• Attempts to exploit authentication and authorization flaws
• Validates input sanitization and output encoding
• Tests for business logic vulnerabilities
• Should be used carefully in production environments due to potential side effects

Note: The DAST scanner is set to passive by default.

DAST has several configuration options that can be applied via environment variables. For a list of all the possible configuration options for DAST, see the DAST documentation.

Authentication configuration

DAST requires authentication configuration in CI/CD jobs to achieve complete security coverage. Authentication enables DAST to simulate real attacks and test user-specific features only accessible after login. The DAST job typically authenticates by submitting login forms in a browser, then verifies success before continuing to crawl the application with saved credentials. Failed authentication stops the job.

Supported authentication methods:

• Single-step login form
• Multi-step login form
• Authentication to URLs outside the target scope

Here is an example for a single-step login form in a Tanuki Shop MR which adds admin authentication to non-default branches.

dast:
  stage: dast
  before_script:
    - echo "DAST_TARGET_URL set to '$DAST_TARGET_URL'" # Dynamically loaded from deploy job
    - echo "DAST_AUTH_URL set to '$DAST_TARGET_URL'" # Dynamically loaded from deploy jobs
  rules:
    - if: $CI_COMMIT_REF_NAME == $CI_DEFAULT_BRANCH
      variables:
        DAST_FULL_SCAN: "false"
    - if: $CI_COMMIT_REF_NAME != $CI_DEFAULT_BRANCH
      variables:
        DAST_FULL_SCAN: "true" # run both passive and active checks
        DAST_AUTH_USERNAME: "[email protected]" # The username to authenticate to in the website
        DAST_AUTH_PASSWORD: "admin123" # The password to authenticate to in the website
        DAST_AUTH_USERNAME_FIELD: "css:input[id=email]" # A selector describing the element used to enter the username on the login form
        DAST_AUTH_PASSWORD_FIELD: "css:input[id=password]" # A selector describing the element used to enter the password on the login form
        DAST_AUTH_SUBMIT_FIELD: "css:button[id=loginButton]" # A selector describing the element clicked on to submit the login form
        DAST_SCOPE_EXCLUDE_ELEMENTS: "css:[id=navbarLogoutButton]" # Comma-separated list of selectors that are ignored when scanning
        DAST_AUTH_REPORT: "true" # generate a report detailing steps taken during the authentication process
        DAST_REQUEST_COOKIES: "welcomebanner_status:dismiss,cookieconsent_status:dismiss" # A cookie name and value to be added to every request
        DAST_CRAWL_GRAPH: "true" # generate an SVG graph of navigation paths visited during crawl phase of the scan
  dependencies:
    - deploy-kubernetes

You can see if the authentication was successful by viewing the job logs:

Once this job completes it provides an authentication report which includes screenshots of the login page:

You can also see more examples on DAST with authentication in our DAST demos group. To learn more about how to perform DAST with authentication with your specific requirements, see the DAST authentication documentation.

Viewing results in MR

GitLab's DAST seamlessly integrates security scanning into your development workflow by displaying results directly within merge requests:

These results include comprehensive vulnerability data within MRs to help developers identify and address security issues before code is merged. Here's what DAST typically reports:

Vulnerability details

• Vulnerability name and type (e.g., SQL injection, XSS, CSRF)
• Severity level (Critical, High, Medium, Low, Info)
• CVSS score when applicable
• Common Weakness Enumeration (CWE) identifier
• Confidence level of the finding

Location information

• URL/endpoint where the vulnerability was detected
• HTTP method used (GET, POST, etc.)
• Request/response details showing the vulnerable interaction
• Parameter names that are vulnerable
• Evidence demonstrating the vulnerability

Technical context

• Description of the vulnerability and potential impact
• Proof of concept showing how the vulnerability can be exploited
• Request/response pairs that triggered the finding
• Scanner details (which DAST tool detected it)

Remediation guidance

• Solution recommendations for fixing the vulnerability
• References to security standards (OWASP, etc.)
• Links to documentation for remediation steps

Viewing results in GitLab Vulnerability Report

For managing vulnerabilities located in the default (or production) branch, the GitLab Vulnerability Report provides a centralized dashboard for monitoring all security findings (in the default branch) across your entire project or organization. This comprehensive view aggregates all security scan results, offering filtering and sorting capabilities to help security teams prioritize remediation efforts.

When selecting a vulnerability, you are taken to its vulnerability page:

Just like in merge requests, the vulnerability page provides comprehensive vulnerability data, as seen above. From here you can triage vulnerabilities by assigning them with a status:

• Needs triage (Default)
• Confirmed
• Dismissed (Acceptable risk, False positive, Mitigating control, Used in tests, Not applicable)
• Resolved

When a vulnerability status is changed, the audit log includes a note of who changed it, when it was changed, and the reason it was changed. This comprehensive system allows security teams to efficiently prioritize, track, and manage vulnerabilities throughout their lifecycle with clear accountability and detailed risk context.

On-demand and scheduled DAST

GitLab provides flexible scanning options beyond standard CI/CD pipeline integration through on-demand and scheduled DAST scans. On-demand scans allow security teams and developers to initiate DAST testing manually whenever needed, without waiting for code commits or pipeline triggers. This capability is particularly valuable for ad-hoc security assessments, incident response scenarios, or when testing specific application features that may not be covered in regular pipeline scans.

On-demand scans can be configured with custom parameters, target URLs, and scanning profiles, making them ideal for focused security testing of particular application components or newly-deployed features. Scheduled DAST scans provide automated, time-based security testing that operates independently of the development workflow. These scans can be configured to run daily, weekly, or at custom intervals, ensuring continuous security monitoring of production applications.

To learn how to implement on-demand or scheduled scans within your project, see the DAST on-demand scan documentation

DAST in compliance workflows

GitLab's security policies framework allows organizations to enforce consistent security standards across all projects, while maintaining flexibility for different teams and environments. Security policies enable centralized governance of DAST scanning requirements, ensuring that critical applications receive appropriate security testing without requiring individual project configuration. By defining security policies at the group or instance level, security teams can mandate DAST scans for specific project types, deployment environments, or risk classifications.

Scan/Pipeline Execution Policies can be configured to automatically trigger DAST scans based on specific conditions such as merge requests to protected branches, scheduled intervals, or deployment events. For example, a policy might require full active DAST scans for all applications before production deployment, while allowing passive scans only for development branches. These policies can include custom variables, authentication configurations, and exclusion rules that are automatically applied to all covered projects, reducing the burden on development teams and ensuring security compliance.

Merge Request Approval Policies provide an additional layer of security governance by enforcing human review for code changes that may impact security. These policies can be configured to require security team approval when DAST scans detect new vulnerabilities, when security findings exceed defined thresholds, or when changes affect security-critical components. For example, a policy might automatically require approval from a designated security engineer when DAST findings include high-severity vulnerabilities, while allowing lower-risk findings to proceed with standard code review processes.

To learn more about GitLab security policies, see the policy documentation. Additionally, for compliance, GitLab provides Security Inventory and Compliance center, which can allow you to oversee if DAST is running in your environment and where it is required.

To learn more about these features, visit our software compliance solutions page.

Summary

GitLab DAST represents a powerful solution for integrating dynamic security testing into modern development workflows. By implementing DAST in your CI/CD pipeline, your team gains the ability to automatically detect runtime vulnerabilities, maintain compliance with security standards, and build more secure applications without sacrificing development velocity.

The key to successful DAST implementation lies in starting with basic configuration and gradually expanding to more sophisticated scanning profiles as your security maturity grows. Begin with simple website scanning, then progressively add authentication, custom exclusions, and advanced reporting to match your specific security requirements.

Remember that DAST is most effective when combined with other security testing approaches. Use it alongside static analysis, dependency scanning, and manual security reviews to create a comprehensive security testing strategy. The automated nature of GitLab DAST ensures that security testing becomes a consistent, repeatable part of your development process rather than an afterthought.

To learn more about GitLab security, check out our security testing solutions page. To get started with GitLab DAST, sign up for a free trial of GitLab Ultimate today.