diff options
Diffstat (limited to 'doc/user/application_security/dast/index.md')
| -rw-r--r-- | doc/user/application_security/dast/index.md | 373 |
1 files changed, 162 insertions, 211 deletions
diff --git a/doc/user/application_security/dast/index.md b/doc/user/application_security/dast/index.md index 209dd7ad251..d3f679fe9dd 100644 --- a/doc/user/application_security/dast/index.md +++ b/doc/user/application_security/dast/index.md @@ -7,125 +7,142 @@ type: reference, howto # Dynamic Application Security Testing (DAST) **(ULTIMATE)** -> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/4348) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 10.4. +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. -Your application may be exposed to a new category of attacks once deployed into a new environment. For -example, application server misconfigurations or incorrect assumptions about security controls may -not be visible from source code alone. Dynamic Application Security Testing (DAST) checks an -application for these types of vulnerabilities in a deployed environment. GitLab DAST uses the -popular open source tool [OWASP Zed Attack Proxy](https://www.zaproxy.org/) to analyze your running -web application. +Dynamic Application Security Testing (DAST) examines applications for +vulnerabilities like these in deployed environments. DAST uses the open source +tool [OWASP Zed Attack Proxy](https://www.zaproxy.org/) for analysis. NOTE: -The whitepaper ["A Seismic Shift in Application Security"](https://about.gitlab.com/resources/whitepaper-seismic-shift-application-security/) -explains how 4 of the top 6 attacks were application based. Download it to learn how to protect your -organization. +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"](https://about.gitlab.com/resources/whitepaper-seismic-shift-application-security/) +whitepaper. -In GitLab, DAST is commonly initiated by a merge request and runs as a job in the CI/CD pipeline. -You can also run a DAST scan on demand, outside the CI/CD pipeline. Your running web application is -analyzed for known vulnerabilities. GitLab checks the DAST report, compares the vulnerabilities -found between the source and target branches, and shows any relevant findings on the merge request. +You can use DAST to examine your web applications: -Note that this comparison logic uses only the latest pipeline executed for the target branch's base -commit. Running the pipeline on any other commit has no effect on the merge request. +- When initiated by a merge request, running as CI/CD pipeline job. +- On demand, outside the CI/CD pipeline. - +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. -## Enable DAST +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. + +## Prerequisite -### Prerequisites +To use DAST, ensure you're using GitLab Runner with the +[`docker` executor](https://docs.gitlab.com/runner/executors/docker.html). -- GitLab Runner with the [`docker` executor](https://docs.gitlab.com/runner/executors/docker.html). +## Enable DAST To enable DAST, either: -- Enable [Auto DAST](../../../topics/autodevops/stages.md#auto-dast), provided by - [Auto DevOps](../../../topics/autodevops/index.md). -- [Include the DAST template](#dast-cicd-template) in your existing `.gitlab-ci.yml` file. +- Enable [Auto DAST](../../../topics/autodevops/stages.md#auto-dast) (provided + by [Auto DevOps](../../../topics/autodevops/index.md)). +- Manually [include the DAST template](#include-the-dast-template) in your existing + `.gitlab-ci.yml` file. -### DAST CI/CD template +### Include the DAST template -The DAST job is defined in a CI/CD template file you reference in your CI/CD configuration file. The -template is included with GitLab. Updates to the template are provided with GitLab upgrades. You -benefit from any improvements and additions. +If you want to manually add DAST to your application, the DAST job is defined +in a CI/CD template file. Updates to the template are provided with GitLab +upgrades, allowing you to benefit from any improvements and additions. -The following templates are available: +To include the DAST template: -- [`DAST.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Security/DAST.gitlab-ci.yml): - Stable version of the DAST CI/CD template. -- [`DAST.latest.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Security/DAST.latest.gitlab-ci.yml): - Latest version of the DAST template. ([Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/254325) - in GitLab 13.8). Please note that the latest version may include breaking changes. Check the - [DAST troubleshooting guide](#troubleshooting) if you experience problems. +1. Select the CI/CD template you want to use: -Use the stable template unless you need a feature provided only in the latest template. + - [`DAST.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Security/DAST.gitlab-ci.yml): + Stable version of the DAST CI/CD template. + - [`DAST.latest.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Security/DAST.latest.gitlab-ci.yml): + Latest version of the DAST template. ([Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/254325) + in GitLab 13.8). -See the CI/CD [documentation](../../../development/cicd/templates.md#latest-version) -on template versioning for more information. + WARNING: + The latest version of the template may include breaking changes. Use the + stable template unless you need a feature provided only in the latest template. -#### Include the DAST template + For more information about template versioning, see the + [CI/CD documentation](../../../development/cicd/templates.md#latest-version). -The method of including the DAST template depends on the GitLab version: +1. Add a `dast` stage to your GitLab CI stages configuration: -- In GitLab 11.9 and later, [include](../../../ci/yaml/README.md#includetemplate) the - `DAST.gitlab-ci.yml` template. + ```yaml + stages: + - dast + ``` - Add the following to your `.gitlab-ci.yml` file: +1. Add the template to GitLab, based on your version of GitLab: - ```yaml - include: - - template: DAST.gitlab-ci.yml + - In GitLab 11.9 and later, [include](../../../ci/yaml/README.md#includetemplate) + the template by adding the following to your `.gitlab-ci.yml` file: - variables: - DAST_WEBSITE: https://example.com - ``` + ```yaml + include: + - template: <template_file.yml> -- In GitLab 11.8 and earlier, copy the template's content into your `.gitlab_ci.yml` file. + variables: + DAST_WEBSITE: https://example.com + ``` -#### Template options + - In GitLab 11.8 and earlier, add the contents of the template to your + `.gitlab_ci.yml` file. -Running a DAST scan requires a URL. There are two ways to define the URL to be scanned by DAST: +1. Define the URL to be scanned by DAST by using one of these methods: -1. Set the `DAST_WEBSITE` [CI/CD variable](../../../ci/yaml/README.md#variables). + - Set the `DAST_WEBSITE` [CI/CD variable](../../../ci/yaml/README.md#variables). + If set, this value takes precedence. -1. Add it in an `environment_url.txt` file at the root of your project. - This is useful for testing in dynamic environments. To run DAST against an application - dynamically created during a GitLab CI/CD pipeline, a job that runs prior to the DAST scan must - persist the application's domain in an `environment_url.txt` file. DAST automatically parses the - `environment_url.txt` file to find its scan target. + - Add the URL in an `environment_url.txt` file at the root of your project. This is + useful for testing in dynamic environments. To run DAST against an application + dynamically created during a GitLab CI/CD pipeline, a job that runs prior to + the DAST scan must persist the application's domain in an `environment_url.txt` + file. DAST automatically parses the `environment_url.txt` file to find its + scan target. - For example, in a job that runs prior to DAST, you could include code that looks similar to: + For example, in a job that runs prior to DAST, you could include code that + looks similar to: - ```yaml - script: - - echo http://${CI_PROJECT_ID}-${CI_ENVIRONMENT_SLUG}.domain.com > environment_url.txt - artifacts: - paths: [environment_url.txt] - when: always - ``` - - You can see an example of this in our [Auto DevOps CI YAML](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Jobs/Deploy.gitlab-ci.yml) file. + ```yaml + script: + - echo http://${CI_PROJECT_ID}-${CI_ENVIRONMENT_SLUG}.domain.com > environment_url.txt + artifacts: + paths: [environment_url.txt] + when: always + ``` -If both values are set, the `DAST_WEBSITE` value takes precedence. + You can see an example of this in our + [Auto DevOps CI YAML](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Jobs/Deploy.gitlab-ci.yml) + file. The included template creates a `dast` job in your CI/CD pipeline and scans your project's running application for possible vulnerabilities. The results are saved as a -[DAST report artifact](../../../ci/pipelines/job_artifacts.md#artifactsreportsdast) -that you can later download and analyze. Due to implementation limitations we +[DAST report artifact](../../../ci/yaml/README.md#artifactsreportsdast) +that you can later download and analyze. Due to implementation limitations, we always take the latest DAST artifact available. Behind the scenes, the [GitLab DAST Docker image](https://gitlab.com/gitlab-org/security-products/dast) -is used to run the tests on the specified URL and scan it for possible vulnerabilities. +is used to run the tests on the specified URL and scan it for possible +vulnerabilities. By default, the DAST template uses the latest major version of the DAST Docker image. Using the `DAST_VERSION` variable, you can choose how DAST updates: -- Automatically update DAST with new features and fixes by pinning to a major version (such as `1`). +- Automatically update DAST with new features and fixes by pinning to a major + version (such as `1`). - Only update fixes by pinning to a minor version (such as `1.6`). - Prevent all updates by pinning to a specific version (such as `1.6.4`). -Find the latest DAST versions on the [Releases](https://gitlab.com/gitlab-org/security-products/dast/-/releases) page. +Find the latest DAST versions on the [Releases](https://gitlab.com/gitlab-org/security-products/dast/-/releases) +page. ## Deployment options @@ -145,7 +162,7 @@ on how to configure Review Apps for DAST. 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 utilize the image as a -[service](../../../ci/docker/using_docker_images.md#what-is-a-service). +[service](../../../ci/services/index.md). By using service definitions in your `gitlab-ci.yml`, you can scan services with the DAST analyzer. @@ -154,7 +171,7 @@ stages: - build - dast -include: +include: - template: DAST.gitlab-ci.yml # Deploys the container to the GitLab container registry @@ -261,7 +278,7 @@ that you periodically confirm the scanner's authentication is still working as t time due to authentication changes to the application. Create masked CI/CD variables to pass the credentials that DAST uses. -To create masked variables for the username and password, see [Create a custom variable in the UI](../../../ci/variables/README.md#create-a-custom-variable-in-the-ui). +To create masked variables for the username and password, see [Create a custom variable in the UI](../../../ci/variables/README.md#custom-cicd-variables). Note that the key of the username variable must be `DAST_USERNAME` and the key of the password variable must be `DAST_PASSWORD`. @@ -287,7 +304,7 @@ variables: ``` The results are saved as a -[DAST report artifact](../../../ci/pipelines/job_artifacts.md#artifactsreportsdast) +[DAST report artifact](../../../ci/yaml/README.md#artifactsreportsdast) that you can later download and analyze. Due to implementation limitations, we always take the latest DAST artifact available. @@ -459,16 +476,14 @@ variables: #### Import API specification from a file -If your API specification is in your repository, you can provide the specification's -filename directly as the target. The specification file is expected to be in the -`/zap/wrk` directory. +If your API specification file is in your repository, you can provide its filename as the target. +The API specification file must be in the `/zap/wrk` directory. ```yaml dast: - script: + before_script: - mkdir -p /zap/wrk - cp api-specification.yml /zap/wrk/api-specification.yml - - /analyze -t $DAST_WEBSITE variables: GIT_STRATEGY: fetch DAST_API_SPECIFICATION: api-specification.yml @@ -486,6 +501,12 @@ host referenced may be different than the host of the API's review instance. This can cause incorrect URLs to be imported, or a scan on an incorrect host. Use the `DAST_API_HOST_OVERRIDE` CI/CD variable to override these values. +WARNING: +When using the API host override feature, you cannot use the `$DAST_WEBSITE` variable to override the hostname. +A host override is _only_ supported when importing the API specification from a URL. Attempts to override the +host throw an error when the API specification is imported from a file. This is due to a limitation in the +ZAP OpenAPI extension. + For example, with a OpenAPI V3 specification containing: ```yaml @@ -505,10 +526,6 @@ variables: DAST_API_HOST_OVERRIDE: api-test.host.com ``` -Note that using a host override is ONLY supported when importing the API specification from a URL. -It doesn't work and is ignored when importing the specification from a file. This is due to a -limitation in the ZAP OpenAPI extension. - #### Authentication using headers Tokens in request headers are often used as a way to authenticate API requests. @@ -526,7 +543,8 @@ variables: ### URL scan -> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/214120) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 13.4. +> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/214120) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 13.4. +> - [Improved](https://gitlab.com/gitlab-org/gitlab/-/issues/273141) in GitLab 13.11. A URL scan allows you to specify which parts of a website are scanned by DAST. @@ -550,26 +568,19 @@ category/shoes/page1.html ``` To scan the URLs in that file, set the CI/CD variable `DAST_PATHS_FILE` to the path of that file. +The file can be checked into the project repository or generated as an artifact by a job that +runs before DAST. + +By default, DAST scans do not clone the project repository. Instruct the DAST job to clone +the project by setting `GIT_STRATEGY` to fetch. Give a file path relative to `CI_PROJECT_DIR` to `DAST_PATHS_FILE`. ```yaml include: - template: DAST.gitlab-ci.yml variables: - DAST_PATHS_FILE: url_file.txt -``` - -By default, DAST scans do not clone the project repository. If the file is checked in to the project, instruct the DAST job to clone the project by setting GIT_STRATEGY to fetch. The file is expected to be in the `/zap/wrk` directory. - -```yaml -dast: - script: - - mkdir -p /zap/wrk - - cp url_file.txt /zap/wrk/url_file.txt - - /analyze -t $DAST_WEBSITE - variables: - GIT_STRATEGY: fetch - DAST_PATHS_FILE: url_file.txt + GIT_STRATEGY: fetch + DAST_PATHS_FILE: url_file.txt # url_file.txt lives in the root directory of the project ``` ##### Use `DAST_PATHS` CI/CD variable @@ -584,7 +595,7 @@ include: - template: DAST.gitlab-ci.yml variables: - DAST_PATHS=/page1.html,/category1/page1.html,/page3.html + DAST_PATHS: "/page1.html,/category1/page1.html,/page3.html" ``` When using `DAST_PATHS` and `DAST_PATHS_FILE`, note the following: @@ -643,7 +654,7 @@ DAST can be [configured](#customizing-the-dast-settings) using CI/CD variables. | `DAST_MASK_HTTP_HEADERS` | string | Comma-separated list of request and response headers to be masked (GitLab 13.1). Must contain **all** headers to be masked. Refer to [list of headers that are masked by default](#hide-sensitive-information). | | `DAST_EXCLUDE_URLS` | URLs | The URLs to skip during the authenticated scan; comma-separated. Regular expression syntax can be used to match multiple URLs. For example, `.*` matches an arbitrary character sequence. Not supported for API scans. | | `DAST_FULL_SCAN_ENABLED` | boolean | Set to `true` to run a [ZAP Full Scan](https://github.com/zaproxy/zaproxy/wiki/ZAP-Full-Scan) instead of a [ZAP Baseline Scan](https://github.com/zaproxy/zaproxy/wiki/ZAP-Baseline-Scan). Default: `false` | -| `DAST_FULL_SCAN_DOMAIN_VALIDATION_REQUIRED` | boolean | Set to `true` to require [domain validation](#domain-validation) when running DAST full scans. Not supported for API scans. Default: `false` | +| `DAST_FULL_SCAN_DOMAIN_VALIDATION_REQUIRED` | boolean | [Deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/293595) in GitLab 13.8, to be removed in 14.0. Set to `true` to require [domain validation](#domain-validation) when running DAST full scans. Not supported for API scans. Default: `false` | | `DAST_AUTO_UPDATE_ADDONS` | boolean | ZAP add-ons are pinned to specific versions in the DAST Docker image. Set to `true` to download the latest versions when the scan starts. Default: `false` | | `DAST_API_HOST_OVERRIDE` | string | Used to override domains defined in API specification files. Only supported when importing the API specification from a URL. Example: `example.com:8080` | | `DAST_EXCLUDE_RULES` | string | Set to a comma-separated list of Vulnerability Rule IDs to exclude them from running during the scan. Rule IDs are numbers and can be found from the DAST log or on the [ZAP project](https://github.com/zaproxy/zaproxy/blob/develop/docs/scanners.md). For example, `HTTP Parameter Override` has a rule ID of `10026`. **Note:** In earlier versions of GitLab the excluded rules were executed but alerts they generated were suppressed. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/118641) in GitLab 12.10. | @@ -656,7 +667,7 @@ DAST can be [configured](#customizing-the-dast-settings) using CI/CD variables. | `DAST_INCLUDE_ALPHA_VULNERABILITIES` | boolean | Set to `true` to include alpha passive and active scan rules. Default: `false`. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/12652) in GitLab 13.1. | | `DAST_USE_AJAX_SPIDER` | boolean | Set to `true` to use the AJAX spider in addition to the traditional spider, useful for crawling sites that require JavaScript. Default: `false`. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/12652) in GitLab 13.1. | | `DAST_PATHS` | string | Set to a comma-separated list of URLs for DAST to scan. For example, `/page1.html,/category1/page3.html,/page2.html`. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/214120) in GitLab 13.4. | -| `DAST_PATHS_FILE` | string | The file path containing the paths within `DAST_WEBSITE` to scan. The file must be plain text with one path per line and be in `/zap/wrk`. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/258825) in GitLab 13.6. | +| `DAST_PATHS_FILE` | string | The file path containing the paths within `DAST_WEBSITE` to scan. The file must be plain text with one path per line. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/258825) in GitLab 13.6. | | `DAST_SUBMIT_FIELD` | string | The `id` or `name` of the element that when clicked submits the login form or the password form of a multi-page login process. [Introduced](https://gitlab.com/gitlab-org/gitlab-ee/issues/9894) in GitLab 12.4. | | `DAST_FIRST_SUBMIT_FIELD` | string | The `id` or `name` of the element that when clicked submits the username form of a multi-page login process. [Introduced](https://gitlab.com/gitlab-org/gitlab-ee/issues/9894) in GitLab 12.4. | | `DAST_ZAP_CLI_OPTIONS` | string | ZAP server command-line options. For example, `-Xmx3072m` would set the Java maximum memory allocation pool size. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/12652) in GitLab 13.1. | @@ -708,6 +719,22 @@ variables: DAST_ZAP_CLI_OPTIONS: "-config replacer.full_list(0).description=auth -config replacer.full_list(0).enabled=true -config replacer.full_list(0).matchtype=REQ_HEADER -config replacer.full_list(0).matchstr=Authorization -config replacer.full_list(0).regex=false -config replacer.full_list(0).replacement=TOKEN" ``` +### Bleeding-edge vulnerability definitions + +ZAP first creates rules in the `alpha` class. After a testing period with +the community, they are promoted to `beta`. DAST uses `beta` definitions by +default. To request `alpha` definitions, use the +`DAST_INCLUDE_ALPHA_VULNERABILITIES` CI/CD variable as shown in the +following configuration: + +```yaml +include: + template: DAST.gitlab-ci.yml + +variables: + DAST_INCLUDE_ALPHA_VULNERABILITIES: "true" +``` + ### Cloning the project's repository The DAST job does not require the project's repository to be present when running, so by default @@ -747,7 +774,7 @@ successfully run. For more information, see [Offline environments](../offline_de To use DAST in an offline environment, you need: -- GitLab Runner with the [`docker` or `kubernetes` executor](#prerequisites). +- GitLab Runner with the [`docker` or `kubernetes` executor](#prerequisite). - Docker Container Registry with a locally available copy of the DAST [container image](https://gitlab.com/gitlab-org/security-products/dast), found in the [DAST container registry](https://gitlab.com/gitlab-org/security-products/dast/container_registry). @@ -798,8 +825,9 @@ Alternatively, you can use the CI/CD variable `SECURE_ANALYZERS_PREFIX` to overr > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/218465) in GitLab 13.2. > - [Improved](https://gitlab.com/gitlab-org/gitlab/-/issues/218465) in GitLab 13.3. -> - The saved scans feature was [added](https://gitlab.com/groups/gitlab-org/-/epics/5100) in -> GitLab 13.9. +> - The saved scans feature was [introduced](https://gitlab.com/groups/gitlab-org/-/epics/5100) in GitLab 13.9. +> - The option to select a branch was [introduced](https://gitlab.com/groups/gitlab-org/-/epics/4847) in GitLab 13.10. +> - DAST branch selection [feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/322672) in GitLab 13.11. An on-demand DAST scan runs outside the DevOps life cycle. Changes in your repository don't trigger the scan. You must start it manually. @@ -811,6 +839,8 @@ An on-demand DAST scan: - Is associated with your project's default branch. - Is saved on creation so it can be run later. +In GitLab 13.10 and later, you can select to run an on-demand scan against a specific branch. + ### On-demand scan modes An on-demand scan can be run in active or passive mode: @@ -843,6 +873,7 @@ To run an on-demand scan, either: 1. From your project's home page, go to **Security & Compliance > On-demand Scans** in the left sidebar. 1. Complete the **Scan name** and **Description** fields. +1. In GitLab 13.10 and later, select the desired branch from the **Branch** dropdown. 1. In **Scanner profile**, select a scanner profile from the dropdown. 1. In **Site profile**, select a site profile from the dropdown. 1. To run the on-demand scan now, select **Save and run scan**. Otherwise select **Save scan** to @@ -877,6 +908,9 @@ To run a saved on-demand scan: 1. Select the **Saved Scans** tab. 1. In the scan's row select **Run scan**. + If the branch saved in the scan no longer exists, you must first + [edit the scan](#edit-an-on-demand-scan), select a new branch, and save the edited scan. + The on-demand DAST scan runs and the project's dashboard shows the results. ### Edit an on-demand scan @@ -911,6 +945,14 @@ A site profile contains the following: - **Profile name**: A name you assign to the site to be scanned. - **Target URL**: The URL that DAST runs against. +- **Excluded URLs**: A comma-separated list of URLs to exclude from the scan. +- **Request headers**: A comma-separated list of HTTP request headers, including names and values. These headers are added to every request made by DAST. +- **Authentication**: + - **Authenticated URL**: The URL of the page containing the sign-in HTML form on the target website. The username and password are submitted with the login form to create an authenticated scan. + - **Username**: The username used to authenticate to the website. + - **Password**: The password used to authenticate to the website. + - **Username form field**: The name of username field at the sign-in HTML form. + - **Password form field**: The name of password field at the sign-in HTML form. #### Site profile validation @@ -926,7 +968,7 @@ follows: - _Header validation_ requires the header `Gitlab-On-Demand-DAST` be added to the target site, with a value unique to the project. The validation process checks that the header is present, and checks its value. - + Both methods are equivalent in functionality. Use whichever is feasible. #### Create a site profile @@ -950,7 +992,9 @@ To edit an existing site profile: 1. In the profile's row select the **More actions** (**{ellipsis_v}**) menu, then select **Edit**. 1. Edit the fields then select **Save profile**. -The site profile is updated with the edited details. +If a site profile is linked to a security policy, a user cannot edit the profile from this page. See +[Scan Policies](../policies/index.md) +for more information. #### Delete a site profile @@ -962,7 +1006,9 @@ To delete an existing site profile: 1. In the profile's row select the **More actions** (**{ellipsis_v}**) menu, then select **Delete**. 1. Select **Delete** to confirm the deletion. -The site profile is deleted. +If a site profile is linked to a security policy, a user cannot delete the profile from this page. +See [Scan Policies](../policies/index.md) +for more information. #### Validate a site profile @@ -1084,7 +1130,9 @@ To edit a scanner profile: 1. Edit the form. 1. Select **Save profile**. -The scanner profile is updated with the edited details. +If a scanner profile is linked to a security policy, a user cannot edit the profile from this page. +See [Scan Policies](../policies/index.md) +for more information. #### Delete a scanner profile @@ -1096,7 +1144,9 @@ To delete a scanner profile: 1. In the scanner's row select the **More actions** (**{ellipsis_v}**) menu, then select **Delete**. 1. Select **Delete**. -The scanner profile is deleted. +If a scanner profile is linked to a security policy, a user cannot delete the profile from this +page. See [Scan Policies](../policies/index.md) +for more information. ## Reports @@ -1145,38 +1195,6 @@ dast: - gl-dast-report.json ``` -## Security Dashboard - -The Security Dashboard is a good place to get an overview of all the security -vulnerabilities in your groups, projects and pipelines. Read more about the -[Security Dashboard](../security_dashboard/index.md). - -## Bleeding-edge vulnerability definitions - -ZAP first creates rules in the `alpha` class. After a testing period with -the community, they are promoted to `beta`. DAST uses `beta` definitions by -default. To request `alpha` definitions, use the -`DAST_INCLUDE_ALPHA_VULNERABILITIES` CI/CD variable as shown in the -following configuration: - -```yaml -include: - template: DAST.gitlab-ci.yml - -variables: - DAST_INCLUDE_ALPHA_VULNERABILITIES: "true" -``` - -## Interacting with the vulnerabilities - -Once a vulnerability is found, you can interact with it. Read more on how to -[address the vulnerabilities](../index.md#addressing-vulnerabilities). - -## Vulnerabilities database update - -For more information about the vulnerabilities database update, check the -[maintenance table](../index.md#maintenance-and-update-of-the-vulnerabilities-database). - ## Optimizing DAST By default, DAST downloads all artifacts defined by previous jobs in the pipeline. If @@ -1188,70 +1206,3 @@ artifacts, add the following to your `gitlab-ci.yml` file: dast: dependencies: [] ``` - -## Troubleshooting - -### Running out of memory - -By default, ZAProxy, which DAST relies on, is allocated memory that sums to 25% -of the total memory on the host. -Since it keeps most of its information in memory during a scan, -it's possible for DAST to run out of memory while scanning large applications. -This results in the following error: - -```plaintext -[zap.out] java.lang.OutOfMemoryError: Java heap space -``` - -Fortunately, it's straightforward to increase the amount of memory available -for DAST by using the `DAST_ZAP_CLI_OPTIONS` CI/CD variable: - -```yaml -include: - - template: DAST.gitlab-ci.yml - -variables: - DAST_ZAP_CLI_OPTIONS: "-Xmx3072m" -``` - -Here, DAST is being allocated 3072 MB. -Change the number after `-Xmx` to the required memory amount. - -### DAST job exceeding the job timeout - -If your DAST job exceeds the job timeout and you need to reduce the scan duration, we shared some tips for optimizing DAST scans in a [blog post](https://about.gitlab.com/blog/2020/08/31/how-to-configure-dast-full-scans-for-complex-web-applications/). - -### Getting warning message `gl-dast-report.json: no matching files` - -For information on this, see the [general Application Security troubleshooting section](../../../ci/pipelines/job_artifacts.md#error-message-no-files-to-upload). - -### Getting error `dast job: chosen stage does not exist` when including DAST CI template - -Newer versions of the DAST CI template do not define stages in order to avoid -overwriting stages from other CI files. If you've recently started using -`DAST.latest.gitlab-ci.yml` or upgraded to a new major release of GitLab and -began receiving this error, you will need to define a `dast` stage with your -other stages. Please note that you must have a running application for DAST to -scan. If your application is set up in your pipeline, it must be deployed - in a stage _before_ the `dast` stage: - -```yaml -stages: - - deploy # DAST needs a running application to scan - - dast - -include: - - template: DAST.latest.gitlab-ci.yml -``` - -<!-- ## Troubleshooting - -Include any troubleshooting steps that you can foresee. If you know beforehand what issues -one might have when setting this up, or when something is changed, or on upgrading, it's -important to describe those, too. Think of things that may go wrong and include them here. -This is important to minimize requests for support, and to avoid doc comments with -questions that you know someone might ask. - -Each scenario can be a third-level heading, e.g. `### Getting error message X`. -If you have none to add when creating a doc, leave this section in place -but commented out to help encourage others to add to it in the future. --> |