Merge branch 'docs/secure-rm-deprecated-jobs' into 'master'

Remove deprecated docs sections of Secure jobs

Closes #63739

See merge request gitlab-org/gitlab-ce!30527

5 files changed, 75 insertions, 523 deletions

diff --git a/doc/user/application_security/container_scanning/index.md b/doc/user/application_security/container_scanning/index.md
index 696446599c8..da75684a3fe 100644
--- a/doc/user/application_security/container_scanning/index.md
+++ b/doc/user/application_security/container_scanning/index.md
@@ -10,7 +10,7 @@ images (or more precisely the containers) for known vulnerabilities by using
 [Clair](https://github.com/coreos/clair) and [clair-scanner](https://github.com/arminc/clair-scanner),
 two open source tools for Vulnerability Static Analysis for containers.
 
-You can take advantage of Container Scanning by either [including the CI job](#including-the-provided-template) in
+You can take advantage of Container Scanning by either [including the CI job](#configuration) in
 your existing `.gitlab-ci.yml` file or by implicitly using
 [Auto Container Scanning](../../../topics/autodevops/index.md#auto-container-scanning-ultimate)
 that is provided by [Auto DevOps](../../../topics/autodevops/index.md).
@@ -55,32 +55,16 @@ To enable Container Scanning in your pipeline, you need:
   [predefined environment variables](../../../ci/variables/predefined_variables.md)
   document.
 
-## Configuring Container Scanning
+## Configuration
 
-To enable Container Scanning in your project, define a job in your
-`.gitlab-ci.yml` file that generates the
-[Container Scanning report artifact](../../../ci/yaml/README.md#artifactsreportscontainer_scanning-ultimate).
+For GitLab 11.9 and later, to enable Container Scanning, you must
+[include](../../../ci/yaml/README.md#includetemplate) the
+[`Container-Scanning.gitlab-ci.yml` template](https://gitlab.com/gitlab-org/gitlab-ee/blob/master/lib/gitlab/ci/templates/Security/Container-Scanning.gitlab-ci.yml)
+that's provided as a part of your GitLab installation.
+For GitLab versions earlier than 11.9, you can copy and use the job as defined
+in that template.
 
-This can be done in two ways:
-
-- For GitLab 11.9 and later, including the provided
-  `Container-Scanning.gitlab-ci.yml` template (recommended).
-- Manually specifying the job definition. Not recommended unless using GitLab
-  11.8 and earlier.
-
-### Including the provided template
-
-NOTE: **Note:**
-The CI/CD Container Scanning template is supported on GitLab 11.9 and later versions.
-For earlier versions, use the [manual job definition](#manual-job-definition-for-gitlab-115-and-later).
-
-A CI/CD [Container Scanning template](https://gitlab.com/gitlab-org/gitlab-ee/blob/master/lib/gitlab/ci/templates/Security/Container-Scanning.gitlab-ci.yml)
-with the default Container Scanning job definition is provided as a part of your GitLab
-installation that you can [include](../../../ci/yaml/README.md#includetemplate)
-in your `.gitlab-ci.yml` file.
-
-To enable Container Scanning using the provided template, add the following to
-your `.gitlab-ci.yml` file:
+Add the following to your `.gitlab-ci.yml` file:
 
 ```yaml
 include:
@@ -89,12 +73,12 @@ include:
 
 The included template will:
 
-- Create a `container_scanning` job in your CI/CD pipeline.
-- Pull the already built Docker image from your project's
-  [Container Registry](../../project/container_registry.md) (see [requirements](#requirements))
-  and scan it for possible vulnerabilities.
+1. Create a `container_scanning` job in your CI/CD pipeline.
+1. Pull the already built Docker image from your project's
+   [Container Registry](../../project/container_registry.md) (see [requirements](#requirements))
+   and scan it for possible vulnerabilities.
 
-The report will be saved as a
+The results will be saved as a
 [Container Scanning report artifact](../../../ci/yaml/README.md#artifactsreportscontainer_scanning-ultimate)
 that you can later download and analyze.
 Due to implementation limitations, we always take the latest Container Scanning
@@ -106,95 +90,6 @@ If you want to whitelist some specific vulnerabilities, you can do so by definin
 them in a YAML file named `clair-whitelist.yml`. Read more in the
 [Clair documentation](https://github.com/arminc/clair-scanner/blob/master/README.md#example-whitelist-yaml-file).
 
-### Manual job definition for GitLab 11.5 and later
-
-CAUTION: **Caution:**
-The job definition shown below is supported on GitLab 11.5 and later versions.
-However, if you're using GitLab 11.9+, it's recommended to use
-[the provided Container Scanning template](#including-the-provided-template).
-
-For GitLab 11.5 and GitLab Runner 11.5 and later, the following `container_scanning`
-job can be added:
-
-```yaml
-container_scanning:
-  image: docker:stable
-  variables:
-    DOCKER_DRIVER: overlay2
-    ## Define two new variables based on GitLab's CI/CD predefined variables
-    ## https://docs.gitlab.com/ee/ci/variables/README.html#predefined-environment-variables
-    CI_APPLICATION_REPOSITORY: $CI_REGISTRY_IMAGE/$CI_COMMIT_REF_SLUG
-    CI_APPLICATION_TAG: $CI_COMMIT_SHA
-    CLAIR_LOCAL_SCAN_VERSION: v2.0.8_fe9b059d930314b54c78f75afe265955faf4fdc1
-  allow_failure: true
-  services:
-    - docker:stable-dind
-  script:
-    - docker run -d --name db arminc/clair-db:latest
-    - docker run -p 6060:6060 --link db:postgres -d --name clair --restart on-failure arminc/clair-local-scan:${CLAIR_LOCAL_SCAN_VERSION}
-    - apk add -U wget ca-certificates
-    - docker pull ${CI_APPLICATION_REPOSITORY}:${CI_APPLICATION_TAG}
-    - wget https://github.com/arminc/clair-scanner/releases/download/v8/clair-scanner_linux_amd64
-    - mv clair-scanner_linux_amd64 clair-scanner
-    - chmod +x clair-scanner
-    - touch clair-whitelist.yml
-    - while( ! wget -q -O /dev/null http://docker:6060/v1/namespaces ) ; do sleep 1 ; done
-    - retries=0
-    - echo "Waiting for clair daemon to start"
-    - while( ! wget -T 10 -q -O /dev/null http://docker:6060/v1/namespaces ) ; do sleep 1 ; echo -n "." ; if [ $retries -eq 10 ] ; then echo " Timeout, aborting." ; exit 1 ; fi ; retries=$(($retries+1)) ; done
-    - ./clair-scanner -c http://docker:6060 --ip $(hostname -i) -r gl-container-scanning-report.json -l clair.log -w clair-whitelist.yml ${CI_APPLICATION_REPOSITORY}:${CI_APPLICATION_TAG} || true
-  artifacts:
-    reports:
-      container_scanning: gl-container-scanning-report.json
-```
-
-### Manual job definition for GitLab 11.4 and earlier (deprecated)
-
-CAUTION: **Deprecated:**
-Before GitLab 11.5, the Container Scanning job and artifact had to be named specifically
-to automatically extract report data and show it in the merge request widget.
-While these old job definitions are still maintained, they have been deprecated
-and may be removed in the next major release, GitLab 12.0. You are strongly
-advised to update your current `.gitlab-ci.yml` configuration to reflect that change.
-
-For GitLab 11.4 and earlier, the Container Scanning job should look like:
-
-```yaml
-container_scanning:
-  image: docker:stable
-  variables:
-    DOCKER_DRIVER: overlay2
-    ## Define two new variables based on GitLab's CI/CD predefined variables
-    ## https://docs.gitlab.com/ee/ci/variables/README.html#predefined-environment-variables
-    CI_APPLICATION_REPOSITORY: $CI_REGISTRY_IMAGE/$CI_COMMIT_REF_SLUG
-    CI_APPLICATION_TAG: $CI_COMMIT_SHA
-    CLAIR_LOCAL_SCAN_VERSION: v2.0.8_fe9b059d930314b54c78f75afe265955faf4fdc1
-  allow_failure: true
-  services:
-    - docker:stable-dind
-  script:
-    - docker run -d --name db arminc/clair-db:latest
-    - docker run -p 6060:6060 --link db:postgres -d --name clair --restart on-failure arminc/clair-local-scan:${CLAIR_LOCAL_SCAN_VERSION}
-    - apk add -U wget ca-certificates
-    - docker pull ${CI_APPLICATION_REPOSITORY}:${CI_APPLICATION_TAG}
-    - wget https://github.com/arminc/clair-scanner/releases/download/v8/clair-scanner_linux_amd64
-    - mv clair-scanner_linux_amd64 clair-scanner
-    - chmod +x clair-scanner
-    - touch clair-whitelist.yml
-    - while( ! wget -q -O /dev/null http://docker:6060/v1/namespaces ) ; do sleep 1 ; done
-    - retries=0
-    - echo "Waiting for clair daemon to start"
-    - while( ! wget -T 10 -q -O /dev/null http://docker:6060/v1/namespaces ) ; do sleep 1 ; echo -n "." ; if [ $retries -eq 10 ] ; then echo " Timeout, aborting." ; exit 1 ; fi ; retries=$(($retries+1)) ; done
-    - ./clair-scanner -c http://docker:6060 --ip $(hostname -i) -r gl-container-scanning-report.json -l clair.log -w clair-whitelist.yml ${CI_APPLICATION_REPOSITORY}:${CI_APPLICATION_TAG} || true
-  artifacts:
-    paths: [gl-container-scanning-report.json]
-```
-
-Alternatively, the job name could be `sast:container`
-and the artifact name could be `gl-sast-container-report.json`.
-These names have been deprecated with GitLab 11.0
-and may be removed in the next major release, GitLab 12.0.
-
 ## Security Dashboard
 
 The Security Dashboard is a good place to get an overview of all the security
diff --git a/doc/user/application_security/dast/index.md b/doc/user/application_security/dast/index.md
index 936703cce32..a0a917c5ebd 100644
--- a/doc/user/application_security/dast/index.md
+++ b/doc/user/application_security/dast/index.md
@@ -14,7 +14,7 @@ Dynamic Application Security Testing (DAST) comes into place.
 If you are using [GitLab CI/CD](../../../ci/README.md), you can analyze your running web application(s)
 for known vulnerabilities using Dynamic Application Security Testing (DAST).
 
-You can take advantage of DAST by either [including the CI job](#configuring-dast) in
+You can take advantage of DAST by either [including the CI job](#configuration) in
 your existing `.gitlab-ci.yml` file or by implicitly using
 [Auto DAST](../../../topics/autodevops/index.md#auto-dast-ultimate)
 that is provided by [Auto DevOps](../../../topics/autodevops/index.md).
@@ -51,30 +51,16 @@ applications while you are developing and testing your applications.
 To run a DAST job, you need GitLab Runner with the
 [`docker` executor](https://docs.gitlab.com/runner/executors/docker.html).
 
-## Configuring DAST
+## Configuration
 
-To enable DAST in your project, define a job in your `.gitlab-ci.yml` file that generates the
-[DAST report artifact](../../../ci/yaml/README.md#artifactsreportsdast-ultimate).
+For GitLab 11.9 and later, to enable DAST, you must
+[include](../../../ci/yaml/README.md#includetemplate) the
+[`DAST.gitlab-ci.yml` template](https://gitlab.com/gitlab-org/gitlab-ee/blob/master/lib/gitlab/ci/templates/Security/DAST.gitlab-ci.yml)
+that's provided as a part of your GitLab installation.
+For GitLab versions earlier than 11.9, you can copy and use the job as defined
+in that template.
 
-This can be done in two ways:
-
-- For GitLab 11.9 and later, including the provided `DAST.gitlab-ci.yml` template (recommended).
-- Manually specifying the job definition. Not recommended unless using GitLab
-  11.8 and earlier.
-
-### Including the provided template
-
-NOTE: **Note:**
-The CI/CD DAST template is supported on GitLab 11.9 and later versions.
-For earlier versions, use the [manual job definition](#manual-job-definition-for-gitlab-115-and-later).
-
-A CI/CD [DAST template](https://gitlab.com/gitlab-org/gitlab-ee/blob/master/lib/gitlab/ci/templates/Security/DAST.gitlab-ci.yml)
-with the default DAST job definition is provided as a part of your GitLab
-installation which you can [include](../../../ci/yaml/README.md#includetemplate)
-in your `.gitlab-ci.yml` file.
-
-To enable DAST using the provided template, add the following to your `.gitlab-ci.yml`
-file:
+Add the following to your `.gitlab-ci.yml` file:
 
 ```yaml
 include:
@@ -84,22 +70,22 @@ variables:
   DAST_WEBSITE: https://example.com
 ```
 
+There are two ways to define the URL to be scanned by DAST:
+
+- Set the `DAST_WEBSITE` [variable](../../../ci/yaml/README.md#variables).
+- Add it in an `environment_url.txt` file at the root of your project.
+
 The included template will create a `dast` job in your CI/CD pipeline and scan
 your project's source code for possible vulnerabilities.
 
-The report will be saved as a
+The results will be saved as a
 [DAST report artifact](../../../ci/yaml/README.md#artifactsreportsdast-ultimate)
 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.
 
-There are two ways to define the URL to be scanned by DAST:
-
-- Set the `DAST_WEBSITE` [variable](../../../ci/yaml/README.md#variables).
-- Add it in an `environment_url.txt` file at the root of your project.
-
-#### Authenticated scan
+### Authenticated scan
 
 It's also possible to authenticate the user before performing the DAST checks:
 
@@ -117,12 +103,12 @@ variables:
   DAST_AUTH_EXCLUDE_URLS: http://example.com/sign-out,http://example.com/sign-out-2 # optional, URLs to skip during the authenticated scan; comma-separated, no spaces in between
 ```
 
-The report will be saved as a
+The results will be saved as a
 [DAST report artifact](../../../ci/yaml/README.md#artifactsreportsdast-ultimate)
 that you can later download and analyze.
 Due to implementation limitations, we always take the latest DAST artifact available.
 
-#### Full scan
+### Full scan
 
 DAST can be configured to perform [ZAP Full Scan](https://github.com/zaproxy/zaproxy/wiki/ZAP-Full-Scan), which
 includes both passive and active scanning against the same target website:
@@ -135,7 +121,7 @@ variables:
   DAST_FULL_SCAN_ENABLED: "true"
 ```
 
-#### Customizing the DAST settings
+### Customizing the DAST settings
 
 The DAST settings can be changed through environment variables by using the
 [`variables`](../../../ci/yaml/README.md#variables) parameter in `.gitlab-ci.yml`.
@@ -155,7 +141,7 @@ variables:
 Because the template is [evaluated before](../../../ci/yaml/README.md#include) the pipeline
 configuration, the last mention of the variable will take precedence.
 
-#### Overriding the DAST template
+### Overriding the DAST template
 
 If you want to override the job definition (for example, change properties like
 `variables` or `dependencies`), you need to declare a `dast` job after the
@@ -176,79 +162,6 @@ As the DAST job belongs to a separate `dast` stage that runs after all
 [default stages](../../../ci/yaml/README.md#stages),
 don't forget to add `stage: dast` when you override the template job definition.
 
-### Manual job definition for GitLab 11.5 and later
-
-For GitLab 11.5 and GitLab Runner 11.5 and later, the following `dast`
-job can be added:
-
-```yaml
-dast:
-  image: registry.gitlab.com/gitlab-org/security-products/zaproxy
-  variables:
-    website: "https://example.com"
-  allow_failure: true
-  script:
-    - mkdir /zap/wrk/
-    - /zap/zap-baseline.py -J gl-dast-report.json -t $website || true
-    - cp /zap/wrk/gl-dast-report.json .
-  artifacts:
-    reports:
-      dast: gl-dast-report.json
-```
-
-Where the `website` variable holds the URL to run the tests against.
-
-For an authenticated scan, use the following definition:
-
-```yaml
-dast:
-  image: registry.gitlab.com/gitlab-org/security-products/zaproxy
-  variables:
-    website: "https://example.com"
-    login_url: "https://example.com/sign-in"
-    username: "john.doe@example.com"
-    password: "john-doe-password"
-  allow_failure: true
-  script:
-    - mkdir /zap/wrk/
-    - /zap/zap-baseline.py -J gl-dast-report.json -t $website
-        --auth-url $login_url
-        --auth-username $username
-        --auth-password $password || true
-    - cp /zap/wrk/gl-dast-report.json .
-  artifacts:
-    reports:
-      dast: gl-dast-report.json
-```
-
-See the [zaproxy documentation](https://gitlab.com/gitlab-org/security-products/zaproxy)
-to learn more about the authentication settings.
-
-### Manual job definition for GitLab 11.4 and earlier (deprecated)
-
-CAUTION: **Caution:**
-Before GitLab 11.5, DAST job and artifact had to be named specifically
-to automatically extract report data and show it in the merge request widget.
-While these old job definitions are still maintained they have been deprecated
-and may be removed in next major release, GitLab 12.0. You are strongly advised
-to update your current `.gitlab-ci.yml` configuration to reflect that change.
-
-For GitLab 11.4 and earlier, the job should look like:
-
-```yaml
-dast:
-  image: registry.gitlab.com/gitlab-org/security-products/zaproxy
-  variables:
-    website: "https://example.com"
-  allow_failure: true
-  script:
-    - mkdir /zap/wrk/
-    - /zap/zap-baseline.py -J gl-dast-report.json -t $website || true
-    - cp /zap/wrk/gl-dast-report.json .
-  artifacts:
-    paths: [gl-dast-report.json]
-```
-
 ## Security Dashboard
 
 The Security Dashboard is a good place to get an overview of all the security
diff --git a/doc/user/application_security/dependency_scanning/index.md b/doc/user/application_security/dependency_scanning/index.md
index 2fe8a6f9029..cb755131171 100644
--- a/doc/user/application_security/dependency_scanning/index.md
+++ b/doc/user/application_security/dependency_scanning/index.md
@@ -8,7 +8,7 @@ in [GitLab Ultimate](https://about.gitlab.com/pricing/) 10.7.
 If you are using [GitLab CI/CD](../../../ci/README.md), you can analyze your dependencies for known
 vulnerabilities using Dependency Scanning.
 
-You can take advantage of Dependency Scanning by either [including the CI job](#including-the-provided-template)
+You can take advantage of Dependency Scanning by either [including the CI job](#configuration)
 in your existing `.gitlab-ci.yml` file or by implicitly using
 [Auto Dependency Scanning](../../../topics/autodevops/index.md#auto-dependency-scanning-ultimate)
 that is provided by [Auto DevOps](../../../topics/autodevops/index.md).
@@ -74,31 +74,16 @@ The Gemnasium client does **NOT** send the exact package versions your project r
 You can disable the remote checks by [using](#customizing-the-dependency-scanning-settings)
 the `DS_DISABLE_REMOTE_CHECKS` environment variable and setting it to `true`.
 
-## Configuring Dependency Scanning
+## Configuration
 
-To enable Dependency Scanning in your project, define a job in your `.gitlab-ci.yml`
-file that generates the
-[Dependency Scanning report artifact](../../../ci/yaml/README.md#artifactsreportsdependency_scanning-ultimate).
+For GitLab 11.9 and later, to enable Dependency Scanning, you must
+[include](../../../ci/yaml/README.md#includetemplate) the
+[`Dependency-Scanning.gitlab-ci.yml` template](https://gitlab.com/gitlab-org/gitlab-ee/blob/master/lib/gitlab/ci/templates/Security/Dependency-Scanning.gitlab-ci.yml)
+that's provided as a part of your GitLab installation.
+For GitLab versions earlier than 11.9, you can copy and use the job as defined
+that template.
 
-This can be done in two ways:
-
-- For GitLab 11.9 and later, including the provided `Dependency-Scanning.gitlab-ci.yml` template (recommended).
-- Manually specifying the job definition. Not recommended unless using GitLab
-  11.8 and earlier.
-
-### Including the provided template
-
-NOTE: **Note:**
-The CI/CD Dependency Scanning template is supported on GitLab 11.9 and later versions.
-For earlier versions, use the [manual job definition](#manual-job-definition-for-gitlab-115-and-later).
-
-A CI/CD [Dependency Scanning template](https://gitlab.com/gitlab-org/gitlab-ee/blob/master/lib/gitlab/ci/templates/Security/Dependency-Scanning.gitlab-ci.yml)
-with the default Dependency Scanning job definition is provided as a part of your GitLab
-installation which you can [include](../../../ci/yaml/README.md#includetemplate)
-in your `.gitlab-ci.yml` file.
-
-To enable Dependency Scanning using the provided template, add the following to
-your `.gitlab-ci.yml` file:
+Add the following to your `.gitlab-ci.yml` file:
 
 ```yaml
 include:
@@ -108,12 +93,12 @@ include:
 The included template will create a `dependency_scanning` job in your CI/CD
 pipeline and scan your project's source code for possible vulnerabilities.
 
-The report will be saved as a
+The results will be saved as a
 [Dependency Scanning report artifact](../../../ci/yaml/README.md#artifactsreportsdependency_scanning-ultimate)
 that you can later download and analyze. Due to implementation limitations, we
 always take the latest Dependency Scanning artifact available.
 
-#### Customizing the Dependency Scanning settings
+### Customizing the Dependency Scanning settings
 
 The Dependency Scanning settings can be changed through [environment variables](#available-variables) by using the
 [`variables`](../../../ci/yaml/README.md#variables) parameter in `.gitlab-ci.yml`.
@@ -131,7 +116,7 @@ variables:
 Because template is [evaluated before](../../../ci/yaml/README.md#include) the pipeline
 configuration, the last mention of the variable will take precedence.
 
-#### Overriding the Dependency Scanning template
+### Overriding the Dependency Scanning template
 
 If you want to override the job definition (for example, change properties like
 `variables` or `dependencies`), you need to declare a `dependency_scanning` job
@@ -146,7 +131,7 @@ dependency_scanning:
     CI_DEBUG_TRACE: "true"
 ```
 
-#### Available variables
+### Available variables
 
 Dependency Scanning can be [configured](#customizing-the-dependency-scanning-settings)
 using environment variables.
@@ -164,82 +149,6 @@ using environment variables.
 | `DS_PULL_ANALYZER_IMAGE_TIMEOUT`        | Time limit when pulling the image of an analyzer. Timeouts are parsed using Go's [`ParseDuration`](https://golang.org/pkg/time/#ParseDuration). Valid time units are `ns`, `us` (or `µs`), `ms`, `s`, `m`, `h`. For example, `300ms`, `1.5h`, or `2h45m`. |
 | `DS_RUN_ANALYZER_TIMEOUT`               | Time limit when running an analyzer. Timeouts are parsed using Go's [`ParseDuration`](https://golang.org/pkg/time/#ParseDuration). Valid time units are `ns`, `us` (or `µs`), `ms`, `s`, `m`, `h`. For example, `300ms`, `1.5h`, or `2h45m`. |
 
-### Manual job definition for GitLab 11.5 and later
-
-For GitLab 11.5 and GitLab Runner 11.5 and later, the following `dependency_scanning`
-job can be added:
-
-```yaml
-dependency_scanning:
-  image: docker:stable
-  variables:
-    DOCKER_DRIVER: overlay2
-  allow_failure: true
-  services:
-    - docker:stable-dind
-  script:
-    - export DS_VERSION=${SP_VERSION:-$(echo "$CI_SERVER_VERSION" | sed 's/^\([0-9]*\)\.\([0-9]*\).*/\1-\2-stable/')}
-    - |
-      docker run \
-      --env DS_ANALYZER_IMAGES \
-      --env DS_ANALYZER_IMAGE_PREFIX \
-      --env DS_ANALYZER_IMAGE_TAG \
-      --env DS_DEFAULT_ANALYZERS \
-      --env DEP_SCAN_DISABLE_REMOTE_CHECKS \
-      --env DS_DOCKER_CLIENT_NEGOTIATION_TIMEOUT \
-      --env DS_PULL_ANALYZER_IMAGE_TIMEOUT \
-      --env DS_RUN_ANALYZER_TIMEOUT \
-      --volume "$PWD:/code" \
-      --volume /var/run/docker.sock:/var/run/docker.sock \
-      "registry.gitlab.com/gitlab-org/security-products/dependency-scanning:$DS_VERSION" /code
-  dependencies: []
-  artifacts:
-    reports:
-      dependency_scanning: gl-dependency-scanning-report.json
-```
-
-You can supply many other [settings variables](#available-variables)
-via `docker run --env` to customize your job execution.
-
-### Manual job definition for GitLab 11.4 and earlier (deprecated)
-
-CAUTION: **Caution:**
-Before GitLab 11.5, the Dependency Scanning job and artifact had to be named specifically
-to automatically extract the report data and show it in the merge request widget.
-While these old job definitions are still maintained, they have been deprecated
-and may be removed in the next major release, GitLab 12.0. You are strongly advised
-to update your current `.gitlab-ci.yml` configuration to reflect that change.
-
-For GitLab 11.4 and earlier, the job should look like:
-
-```yaml
-dependency_scanning:
-  image: docker:stable
-  variables:
-    DOCKER_DRIVER: overlay2
-  allow_failure: true
-  services:
-    - docker:stable-dind
-  script:
-    - export DS_VERSION=${SP_VERSION:-$(echo "$CI_SERVER_VERSION" | sed 's/^\([0-9]*\)\.\([0-9]*\).*/\1-\2-stable/')}
-    - |
-      docker run \
-      --env DS_ANALYZER_IMAGES \
-      --env DS_ANALYZER_IMAGE_PREFIX \
-      --env DS_ANALYZER_IMAGE_TAG \
-      --env DS_DEFAULT_ANALYZERS \
-      --env DS_EXCLUDED_PATHS \
-      --env DEP_SCAN_DISABLE_REMOTE_CHECKS \
-      --env DS_DOCKER_CLIENT_NEGOTIATION_TIMEOUT \
-      --env DS_PULL_ANALYZER_IMAGE_TIMEOUT \
-      --env DS_RUN_ANALYZER_TIMEOUT \
-      --volume "$PWD:/code" \
-      --volume /var/run/docker.sock:/var/run/docker.sock \
-      "registry.gitlab.com/gitlab-org/security-products/dependency-scanning:$DS_VERSION" /code
-  artifacts:
-    paths: [gl-dependency-scanning-report.json]
-```
-
 ## Reports JSON format
 
 CAUTION: **Caution:**
diff --git a/doc/user/application_security/license_management/index.md b/doc/user/application_security/license_management/index.md
index 8eb231f8359..a2a9612286a 100644
--- a/doc/user/application_security/license_management/index.md
+++ b/doc/user/application_security/license_management/index.md
@@ -8,7 +8,7 @@ in [GitLab Ultimate](https://about.gitlab.com/pricing/) 11.0.
 If you are using [GitLab CI/CD](../../../ci/README.md), you can search your project dependencies for their licenses
 using License Management.
 
-You can take advantage of License Management by either [including the job](#configuring-license-management)
+You can take advantage of License Management by either [including the job](#configuration)
 in your existing `.gitlab-ci.yml` file or by implicitly using
 [Auto License Management](../../../topics/autodevops/index.md#auto-license-management-ultimate)
 that is provided by [Auto DevOps](../../../topics/autodevops/index.md).
@@ -65,33 +65,16 @@ The following languages and package managers are supported.
 To run a License Management scanning job, you need GitLab Runner with the
 [`docker` executor](https://docs.gitlab.com/runner/executors/docker.html).
 
-## Configuring License Management
+## Configuration
 
-To enable License Management in your project, define a job in your `.gitlab-ci.yml`
-file that generates the [License Management report artifact](../../../ci/yaml/README.md#artifactsreportslicense_management-ultimate).
+For GitLab 11.9 and later, to enable License Management, you must
+[include](../../../ci/yaml/README.md#includetemplate) the
+[`License-Management.gitlab-ci.yml` template](https://gitlab.com/gitlab-org/gitlab-ee/blob/master/lib/gitlab/ci/templates/Security/License-Management.gitlab-ci.yml)
+that's provided as a part of your GitLab installation.
+For GitLab versions earlier than 11.9, you can copy and use the job as defined
+that template.
 
-This can be done in two ways:
-
-- For GitLab 11.9 and later, including the provided `License-Management.gitlab-ci.yml` template (recommended).
-- Manually specifying the job definition. Not recommended unless using GitLab
-  11.8 and earlier.
-
-The License Management settings can be changed through environment variables by using the
-[`variables`](../../../ci/yaml/README.md#variables) parameter in `.gitlab-ci.yml`. These variables are documented in the [License Management documentation](https://gitlab.com/gitlab-org/security-products/license-management#settings).
-
-### Including the provided template
-
-NOTE: **Note:**
-The CI/CD License Management template is supported on GitLab 11.9 and later versions.
-For earlier versions, use the [manual job definition](#manual-job-definition-for-gitlab-115-and-later).
-
-A CI/CD [License Management template](https://gitlab.com/gitlab-org/gitlab-ee/blob/master/lib/gitlab/ci/templates/Security/License-Management.gitlab-ci.yml)
-with the default License Management job definition is provided as a part of your GitLab
-installation which you can [include](../../../ci/yaml/README.md#includetemplate)
-in your `.gitlab-ci.yml` file.
-
-To enable License Management using the provided template, add the following to
-your `.gitlab-ci.yml` file:
+Add the following to your `.gitlab-ci.yml` file:
 
 ```yaml
 include:
@@ -101,14 +84,17 @@ include:
 The included template will create a `license_management` job in your CI/CD pipeline
 and scan your dependencies to find their licenses.
 
-The report will be saved as a
+The results will be saved as a
 [License Management report artifact](../../../ci/yaml/README.md#artifactsreportslicense_management-ultimate)
 that you can later download and analyze. Due to implementation limitations, we
 always take the latest License Management artifact available. Behind the scenes, the
 [GitLab License Management Docker image](https://gitlab.com/gitlab-org/security-products/license-management)
 is used to detect the languages/frameworks and in turn analyzes the licenses.
 
-#### Installing custom dependencies
+The License Management settings can be changed through environment variables by using the
+[`variables`](../../../ci/yaml/README.md#variables) parameter in `.gitlab-ci.yml`. These variables are documented in the [License Management documentation](https://gitlab.com/gitlab-org/security-products/license-management#settings).
+
+### Installing custom dependencies
 
 > Introduced in [GitLab Ultimate](https://about.gitlab.com/pricing/) 11.4.
 
@@ -136,7 +122,7 @@ variables:
 In this example, `my-custom-install-script.sh` is a shell script at the root
 directory of your project.
 
-#### Overriding the template
+### Overriding the template
 
 If you want to override the job definition (for example, change properties like
 `variables` or `dependencies`), you need to declare a `license_management` job
@@ -151,7 +137,7 @@ license_management:
     CI_DEBUG_TRACE: "true"
 ```
 
-#### Configuring Maven projects
+### Configuring Maven projects
 
 The License Management tool provides a `MAVEN_CLI_OPTS` environment variable which can hold
 the command line arguments to pass to the `mvn install` command which is executed under the hood.
@@ -192,67 +178,6 @@ license_management:
     LM_PYTHON_VERSION: 3
 ```
 
-### Manual job definition for GitLab 11.5 and later
-
-For GitLab 11.5 and GitLab Runner 11.5 and later, the following `license_management`
-job can be added:
-
-```yaml
-license_management:
-  image:
-    name: "registry.gitlab.com/gitlab-org/security-products/license-management:$CI_SERVER_VERSION_MAJOR-$CI_SERVER_VERSION_MINOR-stable"
-    entrypoint: [""]
-  stage: test
-  allow_failure: true
-  script:
-    - /run.sh analyze .
-  artifacts:
-    reports:
-      license_management: gl-license-management-report.json
-```
-
-If you want to install custom project dependencies via the `SETUP_CMD` variable:
-
-```yaml
-license_management:
-  image:
-    name: "registry.gitlab.com/gitlab-org/security-products/license-management:$CI_SERVER_VERSION_MAJOR-$CI_SERVER_VERSION_MINOR-stable"
-    entrypoint: [""]
-  stage: test
-  variables:
-    SETUP_CMD: ./my-custom-install-script.sh
-  allow_failure: true
-  script:
-    - /run.sh analyze .
-  artifacts:
-    reports:
-      license_management: gl-license-management-report.json
-```
-
-### Manual job definition for GitLab 11.4 and earlier (deprecated)
-
-CAUTION: **Caution:**
-Before GitLab 11.5, the License Management job and artifact had to be named specifically
-to automatically extract the report data and show it in the merge request widget.
-While these old job definitions are still maintained, they have been deprecated
-and may be removed in the next major release, GitLab 12.0. You are strongly advised
-to update your current `.gitlab-ci.yml` configuration to reflect that change.
-
-For GitLab 11.4 and earlier, the job should look like:
-
-```yaml
-license_management:
-  image:
-    name: "registry.gitlab.com/gitlab-org/security-products/license-management:$CI_SERVER_VERSION_MAJOR-$CI_SERVER_VERSION_MINOR-stable"
-    entrypoint: [""]
-  stage: test
-  allow_failure: true
-  script:
-    - /run.sh analyze .
-  artifacts:
-    paths: [gl-license-management-report.json]
-```
-
 ## Project policies for License Management
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-ee/issues/5940)
@@ -279,8 +204,6 @@ To approve or blacklist a license:
 1. Select the **Approve** or **Blacklist** radio button to approve or blacklist respectively
    the selected license.
 
-
-
 To modify an existing license:
 
 1. In the **License Management** list, click the **Approved/Declined** dropdown to change it to the desired status.
@@ -293,8 +216,6 @@ Searching for Licenses:
 
    ![License Management Search](img/license_management_search.png)
 
-
-
 ## License Management report under pipelines
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-ee/issues/5491)
diff --git a/doc/user/application_security/sast/index.md b/doc/user/application_security/sast/index.md
index 84b45cbe6e6..1f9fd9d4e18 100644
--- a/doc/user/application_security/sast/index.md
+++ b/doc/user/application_security/sast/index.md
@@ -13,7 +13,7 @@ to learn how to protect your organization.
 If you are using [GitLab CI/CD](../../../ci/README.md), you can analyze your source code for known
 vulnerabilities using Static Application Security Testing (SAST).
 
-You can take advantage of SAST by either [including the CI job](#configuring-sast) in
+You can take advantage of SAST by either [including the CI job](#configuration) in
 your existing `.gitlab-ci.yml` file or by implicitly using
 [Auto SAST](../../../topics/autodevops/index.md#auto-sast-ultimate)
 that is provided by [Auto DevOps](../../../topics/autodevops/index.md).
@@ -73,30 +73,16 @@ The Java analyzers can also be used for variants like the
 [Gradle wrapper](https://docs.gradle.org/current/userguide/gradle_wrapper.html),
 [Grails](https://grails.org/) and the [Maven wrapper](https://github.com/takari/maven-wrapper).
 
-## Configuring SAST
+## Configuration
 
-To enable SAST in your project, define a job in your `.gitlab-ci.yml` file that generates the
-[SAST report artifact](../../../ci/yaml/README.md#artifactsreportssast-ultimate).
+For GitLab 11.9 and later, to enable SAST, you must
+[include](../../../ci/yaml/README.md#includetemplate) the
+[`SAST.gitlab-ci.yml` template](https://gitlab.com/gitlab-org/gitlab-ee/blob/master/lib/gitlab/ci/templates/Security/SAST.gitlab-ci.yml)
+that's provided as a part of your GitLab installation.
+For GitLab versions earlier than 11.9, you can copy and use the job as defined
+that template.
 
-This can be done in two ways:
-
-- For GitLab 11.9 and later, including the provided `SAST.gitlab-ci.yml` template (recommended).
-- Manually specifying the job definition. Not recommended unless using GitLab
-  11.8 and earlier.
-
-### Including the provided template
-
-NOTE: **Note:**
-The CI/CD SAST template is supported on GitLab 11.9 and later versions.
-For earlier versions, use the [manual job definition](#manual-job-definition-for-gitlab-115-and-later).
-
-A CI/CD [SAST template](https://gitlab.com/gitlab-org/gitlab-ee/blob/master/lib/gitlab/ci/templates/Security/SAST.gitlab-ci.yml)
-with the default SAST job definition is provided as a part of your GitLab
-installation which you can [include](../../../ci/yaml/README.md#includetemplate)
-in your `.gitlab-ci.yml` file.
-
-To enable SAST using the provided template, add the following to your `.gitlab-ci.yml`
-file:
+Add the following to your `.gitlab-ci.yml` file:
 
 ```yaml
 include:
@@ -106,14 +92,14 @@ include:
 The included template will create a `sast` job in your CI/CD pipeline and scan
 your project's source code for possible vulnerabilities.
 
-The report will be saved as a
+The results will be saved as a
 [SAST report artifact](../../../ci/yaml/README.md#artifactsreportssast-ultimate)
 that you can later download and analyze. Due to implementation limitations, we
 always take the latest SAST artifact available. Behind the scenes, the
 [GitLab SAST Docker image](https://gitlab.com/gitlab-org/security-products/sast)
 is used to detect the languages/frameworks and in turn runs the matching scan tools.
 
-#### Customizing the SAST settings
+### Customizing the SAST settings
 
 The SAST settings can be changed through environment variables by using the
 [`variables`](../../../ci/yaml/README.md#variables) parameter in `.gitlab-ci.yml`.
@@ -134,7 +120,7 @@ variables:
 Because the template is [evaluated before](../../../ci/yaml/README.md#include)
 the pipeline configuration, the last mention of the variable will take precedence.
 
-#### Overriding the SAST template
+### Overriding the SAST template
 
 If you want to override the job definition (for example, change properties like
 `variables` or `dependencies`), you need to declare a `sast` job after the
@@ -149,78 +135,6 @@ sast:
     CI_DEBUG_TRACE: "true"
 ```
 
-### Manual job definition for GitLab 11.5 and later
-
-For GitLab 11.5 and GitLab Runner 11.5 and later, the following `sast`
-job can be added:
-
-```yaml
-sast:
-  stage: test
-  image: docker:stable
-  variables:
-    DOCKER_DRIVER: overlay2
-  allow_failure: true
-  services:
-    - docker:stable-dind
-  script:
-    - export SAST_VERSION=${SP_VERSION:-$(echo "$CI_SERVER_VERSION" | sed 's/^\([0-9]*\)\.\([0-9]*\).*/\1-\2-stable/')}
-    - |
-      docker run \
-        --env SAST_ANALYZER_IMAGES \
-        --env SAST_ANALYZER_IMAGE_PREFIX \
-        --env SAST_ANALYZER_IMAGE_TAG \
-        --env SAST_DEFAULT_ANALYZERS \
-        --env SAST_EXCLUDED_PATHS \
-        --env SAST_BANDIT_EXCLUDED_PATHS \
-        --env SAST_BRAKEMAN_LEVEL \
-        --env SAST_GOSEC_LEVEL \
-        --env SAST_FLAWFINDER_LEVEL \
-        --env SAST_DOCKER_CLIENT_NEGOTIATION_TIMEOUT \
-        --env SAST_PULL_ANALYZER_IMAGE_TIMEOUT \
-        --env SAST_RUN_ANALYZER_TIMEOUT \
-        --volume "$PWD:/code" \
-        --volume /var/run/docker.sock:/var/run/docker.sock \
-        "registry.gitlab.com/gitlab-org/security-products/sast:$SAST_VERSION" /app/bin/run /code
-  dependencies: []
-  artifacts:
-    reports:
-      sast: gl-sast-report.json
-```
-
-You can supply many other [settings variables](https://gitlab.com/gitlab-org/security-products/sast#settings)
-via `docker run --env` to customize your job execution.
-
-### Manual job definition for GitLab 11.4 and earlier (deprecated)
-
-CAUTION: **Deprecated:**
-Before GitLab 11.5, the SAST job and artifact had to be named specifically
-to automatically extract report data and show it in the merge request widget.
-While these old job definitions are still maintained, they have been deprecated
-and may be removed in the next major release, GitLab 12.0. You are strongly
-advised to update your current `.gitlab-ci.yml` configuration to reflect that change.
-
-For GitLab 11.4 and earlier, the SAST job should look like:
-
-```yaml
-sast:
-  image: docker:stable
-  variables:
-    DOCKER_DRIVER: overlay2
-  allow_failure: true
-  services:
-    - docker:stable-dind
-  script:
-    - export SAST_VERSION=${SP_VERSION:-$(echo "$CI_SERVER_VERSION" | sed 's/^\([0-9]*\)\.\([0-9]*\).*/\1-\2-stable/')}
-    - docker run
-        --env SAST_CONFIDENCE_LEVEL="${SAST_CONFIDENCE_LEVEL:-3}"
-        --volume "$PWD:/code"
-        --volume /var/run/docker.sock:/var/run/docker.sock
-        "registry.gitlab.com/gitlab-org/security-products/sast:$SAST_VERSION" /app/bin/run /code
-  artifacts:
-    paths: [gl-sast-report.json]
-```
-
 ## Reports JSON format
 
 CAUTION: **Caution:**