Add latest changes from gitlab-org/gitlab@master

5 files changed, 27 insertions, 25 deletions

diff --git a/doc/user/application_security/container_scanning/index.md b/doc/user/application_security/container_scanning/index.md
index 801cacac958..610e11b18a9 100644
--- a/doc/user/application_security/container_scanning/index.md
+++ b/doc/user/application_security/container_scanning/index.md
@@ -180,7 +180,7 @@ using environment variables.
 | `CLAIR_DB_CONNECTION_STRING`   | This variable represents the [connection string](https://www.postgresql.org/docs/9.3/libpq-connect.html#AEN39692) to the [PostgreSQL server hosting the vulnerabilities definitions](https://hub.docker.com/r/arminc/clair-db) database and **shouldn't be changed** unless you're running the image locally as described in the [Running the standalone Container Scanning Tool](#running-the-standalone-container-scanning-tool) section. The host value for the connection string must match the [alias](https://gitlab.com/gitlab-org/gitlab/-/blob/898c5da43504eba87b749625da50098d345b60d6/lib/gitlab/ci/templates/Security/Container-Scanning.gitlab-ci.yml#L23) value of the `Container-Scanning.gitlab-ci.yml` template file, which defaults to `clair-vulnerabilities-db`. | `postgresql://postgres:password@clair-vulnerabilities-db:5432/postgres?sslmode=disable&statement_timeout=60000` |
 | `CI_APPLICATION_REPOSITORY`    | Docker repository URL for the image to be scanned.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                 | `$CI_REGISTRY_IMAGE/$CI_COMMIT_REF_SLUG`                                                                        |
 | `CI_APPLICATION_TAG`           | Docker respository tag for the image to be scanned.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                | `$CI_COMMIT_SHA`                                                                                                |
-| `CLAIR_DB_IMAGE`               | The Docker image name and tag for the [PostgreSQL server hosting the vulnerabilities definitions](https://hub.docker.com/r/arminc/clair-db). It can be useful to override this value with a specific version, for example, to provide a consistent set of vulnerabilities for integration testing purposes, or to refer to a locally hosted vulnerabilities database for an on-premise air-gapped installation.                                                                                                                                                                                                                                                                                                                                                                      | `arminc/clair-db:latest`                                                                                        |
+| `CLAIR_DB_IMAGE`               | The Docker image name and tag for the [PostgreSQL server hosting the vulnerabilities definitions](https://hub.docker.com/r/arminc/clair-db). It can be useful to override this value with a specific version, for example, to provide a consistent set of vulnerabilities for integration testing purposes, or to refer to a locally hosted vulnerabilities database for an on-premise offline installation.                                                                                                                                                                                                                                                                                                                                                                      | `arminc/clair-db:latest`                                                                                        |
 | `CLAIR_DB_IMAGE_TAG`           | (**DEPRECATED - use `CLAIR_DB_IMAGE` instead**) The Docker image tag for the [PostgreSQL server hosting the vulnerabilities definitions](https://hub.docker.com/r/arminc/clair-db). It can be useful to override this value with a specific version, for example, to provide a consistent set of vulnerabilities for integration testing purposes.                                                                                                                                                                                                                                                                                                                                                                                                                                   | `latest`                                                                                                        |
 | `DOCKERFILE_PATH`              | The path to the `Dockerfile` to be used for generating remediations. By default, the scanner will look for a file named `Dockerfile` in the root directory of the project, so this variable should only be configured if your `Dockerfile` is in a non-standard location, such as a subdirectory. See [Solutions for vulnerabilities](#solutions-for-vulnerabilities-auto-remediation) for more details.                                                                                                                                                                                                                                                                                                                                                                          | `Dockerfile`                                                                                                    |
 | `ADDITIONAL_CA_CERT_BUNDLE`   | Bundle of CA certs that you want to trust. | "" |
@@ -210,7 +210,7 @@ If you want to whitelist specific vulnerabilities, you'll need to:
    in the [whitelist example file](https://github.com/arminc/clair-scanner/blob/v12/example-whitelist.yaml).
 1. Add the `clair-whitelist.yml` file to the Git repository of your project.
 
-### Running Container Scanning in an offline environment deployment
+### Running Container Scanning in an offline environment
 
 Container Scanning can be executed on an offline GitLab Ultimate installation by using the following process:
 
diff --git a/doc/user/application_security/dast/index.md b/doc/user/application_security/dast/index.md
index c595eee0f0a..e60cf095f3f 100644
--- a/doc/user/application_security/dast/index.md
+++ b/doc/user/application_security/dast/index.md
@@ -461,7 +461,7 @@ dast:
 The DAST job does not require the project's repository to be present when running, so by default
 [`GIT_STRATEGY`](../../../ci/yaml/README.md#git-strategy) is set to `none`.
 
-## Running DAST in an offline environment deployment
+## Running DAST in an offline environment
 
 DAST can be executed on an offline GitLab Ultimate installation by using the following process:
 
diff --git a/doc/user/application_security/dependency_scanning/index.md b/doc/user/application_security/dependency_scanning/index.md
index 352fdb64d07..723f4b8acbc 100644
--- a/doc/user/application_security/dependency_scanning/index.md
+++ b/doc/user/application_security/dependency_scanning/index.md
@@ -167,7 +167,7 @@ The following variables are used for configuring specific analyzers (used for a
 | `DS_PIP_DEPENDENCY_PATH`                | `gemnasium-python` |                              | Path to load Python pip dependencies from. ([Introduced](https://gitlab.com/gitlab-org/gitlab/issues/12412) in GitLab 12.2) |
 | `DS_PYTHON_VERSION`                     | `retire.js`        |                              | Version of Python. If set to 2, dependencies are installed using Python 2.7 instead of Python 3.6. ([Introduced](https://gitlab.com/gitlab-org/gitlab/issues/12296) in GitLab 12.1)|
 | `MAVEN_CLI_OPTS`                        | `gemnasium-maven`  | `"-DskipTests --batch-mode"` | List of command line arguments that will be passed to `maven` by the analyzer. See an example for [using private repos](#using-private-maven-repos). |
-| `BUNDLER_AUDIT_UPDATE_DISABLED`         | `bundler-audit`    | `false`                      | Disable automatic updates for the `bundler-audit` analyzer. Useful if you're running Dependency Scanning in an offline, air-gapped environment.|
+| `BUNDLER_AUDIT_UPDATE_DISABLED`         | `bundler-audit`    | `false`                      | Disable automatic updates for the `bundler-audit` analyzer. Useful if you're running Dependency Scanning in an offline environment. |
 | `BUNDLER_AUDIT_ADVISORY_DB_URL`         | `bundler-audit`    | `https://github.com/rubysec/ruby-advisory-db` | URL of the advisory database used by bundler-audit. |
 | `BUNDLER_AUDIT_ADVISORY_DB_REF_NAME`    | `bundler-audit`    | `master`                     | Git ref for the advisory database specified by `BUNDLER_AUDIT_ADVISORY_DB_URL`. |
 | `RETIREJS_JS_ADVISORY_DB`               | `retire.js`        | `https://raw.githubusercontent.com/RetireJS/retire.js/master/repository/jsrepository.json` | Path or URL to Retire.js js vulnerability data file. |
diff --git a/doc/user/application_security/offline_deployments/index.md b/doc/user/application_security/offline_deployments/index.md
index e548d2128b4..4511b4e80d6 100644
--- a/doc/user/application_security/offline_deployments/index.md
+++ b/doc/user/application_security/offline_deployments/index.md
@@ -2,15 +2,15 @@
 type: reference, howto
 ---
 
-# Offline environment deployments
+# Offline environments
 
-It is possible to run most of the GitLab security scanners when not
-connected to the internet.
+It's possible to run most of the GitLab security scanners when not connected to the internet.
 
-This document describes how to operate Secure Categories (that is, scanner types) in an offline environment. These instructions also apply to
-self-managed installations that are secured, have security policies (for example, firewall policies), or are otherwise restricted from
-accessing the full internet. GitLab refers to these deployments as _offline environment deployments_.
-Other common names include:
+This document describes how to operate Secure Categories (that is, scanner types) in an offline
+environment. These instructions also apply to self-managed installations that are secured, have
+security policies (for example, firewall policies), or are otherwise restricted from accessing the
+full internet. GitLab refers to these environments as _offline environments_. Other common names
+include:
 
 - Air-gapped environments
 - Limited connectivity environments
@@ -21,13 +21,13 @@ These environments have physical barriers or security policies (for example, fir
 or limit internet access. These instructions are designed for physically disconnected networks, but
 can also be followed in these other use cases.
 
-## Offline environments
+## Defining offline environments
 
-In this situation, the GitLab instance can be one or more servers and services that can communicate
-on a local network, but with no or very restricted access to the internet. Assume anything within
-the GitLab instance and supporting infrastructure (for example, a private Maven repository) can be
-accessed through a local network connection. Assume any files from the internet must come in through
-physical media (USB drive, hard drive, writeable DVD, etc.).
+In an offline environment, the GitLab instance can be one or more servers and services that can
+communicate on a local network, but with no or very restricted access to the internet. Assume
+anything within the GitLab instance and supporting infrastructure (for example, a private Maven
+repository) can be accessed through a local network connection. Assume any files from the internet
+must come in through physical media (USB drive, hard drive, writeable DVD, etc.).
 
 ## Overview
 
@@ -43,7 +43,7 @@ an internet-connected GitLab installation, GitLab checks the GitLab.com-hosted
 container registry to check that you have the latest versions of these Docker images
 and possibly connect to package repositories to install necessary dependencies.
 
-In an air-gapped environment, these checks must be disabled so that GitLab.com is not
+In an offline environment, these checks must be disabled so that GitLab.com isn't
 queried. Because the GitLab.com registry and repositories are not available,
 you must update each of the scanners to either reference a different,
 internally-hosted registry or provide access to the individual scanner images.
@@ -55,9 +55,11 @@ mirroring the packages inside your own offline network.
 
 ### Interacting with the vulnerabilities
 
-Once a vulnerability is found, you can interact with it. Read more on how to [interact with the vulnerabilities](../index.md#interacting-with-the-vulnerabilities).
+Once a vulnerability is found, you can interact with it. Read more on how to
+[interact with the vulnerabilities](../index.md#interacting-with-the-vulnerabilities).
 
-Please note that in some cases the reported vulnerabilities provide metadata that can contain external links exposed in the UI. These links might not be accessible within an air-gapped (or offline) environment.
+Please note that in some cases the reported vulnerabilities provide metadata that can contain
+external links exposed in the UI. These links might not be accessible within an offline environment.
 
 ### Scanner signature and rule updates
 
@@ -73,6 +75,6 @@ hosted within your network.
 Each individual scanner may be slightly different than the steps described
 above. You can find more info at each of the pages below:
 
-- [Container scanning offline directions](../container_scanning/index.md#running-container-scanning-in-an-offline-environment-deployment)
-- [SAST offline directions](../sast/index.md#gitlab-sast-in-an-offline-environment-deployment)
-- [DAST offline directions](../dast/index.md#running-dast-in-an-offline-environment-deployment)
+- [Container scanning offline directions](../container_scanning/index.md#running-container-scanning-in-an-offline-environment)
+- [SAST offline directions](../sast/index.md#gitlab-sast-in-an-offline-environment)
+- [DAST offline directions](../dast/index.md#running-dast-in-an-offline-environment)
diff --git a/doc/user/application_security/sast/index.md b/doc/user/application_security/sast/index.md
index 7d9717b049d..64a8b1b40dd 100644
--- a/doc/user/application_security/sast/index.md
+++ b/doc/user/application_security/sast/index.md
@@ -491,10 +491,10 @@ Once a vulnerability is found, you can interact with it. Read more on how to
 For more information about the vulnerabilities database update, check the
 [maintenance table](../index.md#maintenance-and-update-of-the-vulnerabilities-database).
 
-## GitLab SAST in an offline environment deployment
+## GitLab SAST in an offline environment
 
 For self-managed GitLab instances in an environment with limited, restricted, or intermittent access
-to external resources via the internet, some adjustments are required for the SAST job to
+to external resources through the internet, some adjustments are required for the SAST job to
 successfully run.
 
 ### Requirements for offline SAST