Dynamic Application Security Testing (DAST)

If you deploy your web application into a new environment, your application may become exposed to new types of attacks. For example, misconfigurations of your application server or incorrect assumptions about security controls may not be visible from the source code.

Dynamic Application Security Testing (DAST) examines applications for vulnerabilities like these in deployed environments. DAST uses the open source tool OWASP Zed Attack Proxy for analysis.

After DAST creates its report, GitLab evaluates it for discovered vulnerabilities between the source and target branches. Relevant findings are noted in the merge request.

The comparison logic uses only the latest pipeline executed for the target branch’s base commit. Running the pipeline on other commits has no effect on the merge request.

note
To learn how four of the top six attacks were application-based and how to protect your organization, download our “A Seismic Shift in Application Security” whitepaper.

DAST application analysis

DAST can analyze applications in two ways:

  • Passive scan only (DAST default). DAST executes ZAP’s Baseline Scan and doesn’t actively attack your application.
  • Passive and active scan. DAST can be configured to also perform an active scan to attack your application and produce a more extensive security report. It can be very useful when combined with Review Apps.
note
A pipeline may consist of multiple jobs, including SAST and DAST scanning. If any job fails to finish for any reason, the security dashboard doesn’t show DAST scanner output. For example, if the DAST job finishes but the SAST job fails, the security dashboard doesn’t show DAST results. On failure, the analyzer outputs an exit code.

Prerequisites

Deployment options

Depending on the complexity of the target application, there are a few options as to how to deploy and configure the DAST template. We provided a set of example applications with their configurations in our DAST demonstrations project.

Review Apps

Review Apps are the most involved method of deploying your DAST target application. To assist in the process, we created a Review App deployment using Google Kubernetes Engine (GKE). This example can be found in our Review Apps - GKE project, along with detailed instructions in the README.md on how to configure Review Apps for DAST.

Docker Services

If your application utilizes Docker containers you have another option for deploying and scanning with DAST. After your Docker build job completes and your image is added to your container registry, you can use the image as a service.

By using service definitions in your .gitlab-ci.yml, you can scan services with the DAST analyzer.

stages:
  - build
  - dast

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

# Deploys the container to the GitLab container registry
deploy:
  services:
  - name: docker:dind
    alias: dind
  image: docker:19.03.5
  stage: build
  script:
    - docker login -u gitlab-ci-token -p $CI_JOB_TOKEN $CI_REGISTRY
    - docker pull $CI_REGISTRY_IMAGE:latest || true
    - docker build --tag $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA --tag $CI_REGISTRY_IMAGE:latest .
    - docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
    - docker push $CI_REGISTRY_IMAGE:latest

services: # use services to link your app container to the dast job
  - name: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
    alias: yourapp

variables:
  DAST_FULL_SCAN_ENABLED: "true" # do a full scan
  DAST_BROWSER_SCAN: "true" # use the browser-based GitLab DAST crawler

Most applications depend on multiple services such as databases or caching services. By default, services defined in the services fields cannot communicate with each another. To allow communication between services, enable the FF_NETWORK_PER_BUILD feature flag.

variables:
  FF_NETWORK_PER_BUILD: "true" # enable network per build so all services can communicate on the same network

services: # use services to link the container to the dast job
  - name: mongo:latest
    alias: mongo
  - name: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
    alias: yourapp

DAST job order

When using the DAST.gitlab-ci.yml template, the dast stage is run last as shown in the example below. To ensure DAST scans the latest code, deploy your application in a stage before the dast stage.

  stages:
    - build
    - test
    - deploy
    - dast

Take care if your pipeline is configured to deploy to the same web server in each run. Running a pipeline while another is still running could result in one pipeline overwriting the code from another pipeline. The site to be scanned should be excluded from changes for the duration of a DAST scan. The only changes to the site should be from the DAST scanner.

Changes to the site during a scan from any of the following could lead to inaccurate results:

  • Users.
  • Scheduled tasks.
  • Database changes.
  • Code changes.
  • Other pipelines.
  • Other scanners.

DAST run options

You can use DAST to examine your web application:

  • Automatically, initiated by a merge request.
  • Manually, initiated on demand.

Some of the differences between these run options:

Automatic scan On-demand scan
DAST scan is initiated by a merge request. DAST scan is initiated manually, outside the DevOps life cycle.
CI/CD variables are sourced from .gitlab-ci.yml. CI/CD variables are provided in the UI.
All DAST CI/CD variables available. Subset of DAST CI/CD variables available.
DAST.gitlab-ci.yml template. DAST-On-Demand-Scan.gitlab-ci.yml template.

Enable automatic DAST run

To enable DAST to run automatically, either: