Merge branch 'docs-secure-environment-variables' into 'master'

Change usage of variables terminology in Secure docs

See merge request gitlab-org/gitlab!54174

doc/.vale/gitlab/Acronyms.yml

@@ -132,6 +132,7 @@ exceptions:
   - SMTP
   - SOC
   - SOX
+  - SPDX
   - SPF
   - SQL
   - SSD
@@ -164,4 +165,5 @@ exceptions:
   - XML
   - XSS
   - YAML
+  - ZAP
   - ZIP

doc/security/README.md

@@ -23,7 +23,7 @@ type: index
 - [Send email confirmation on sign-up](user_email_confirmation.md)
 - [Security of running jobs](https://docs.gitlab.com/runner/security/)
 - [Proxying images](asset_proxy.md)
-- [CI/CD environment variables](cicd_environment_variables.md)
+- [CI/CD variables](cicd_variables.md)
 
 ## Securing your GitLab installation
 

doc/security/cicd_environment_variables.md

 ---
-stage: Release
-group: Release
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
+redirect_to: 'cicd_variables.md'
 ---
 
-# CI/CD Environment Variables
+This document was moved to [another location](cicd_variables.md).
 
-Environment variables are applied to environments via the runner and can be set from the project's **Settings > CI/CD** page.
-
-The values are encrypted using [`aes-256-cbc`](https://en.wikipedia.org/wiki/Advanced_Encryption_Standard) and stored in the database.
-
-This data can only be decrypted with a valid [secrets file](../raketasks/backup_restore.md#when-the-secrets-file-is-lost).
+<!-- This redirect file can be deleted after 2021-05-15. -->
+<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/#move-or-rename-a-page -->

doc/security/cicd_variables.md

+---
+stage: Secure
+group: None
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
+---
+
+# CI/CD Variables
+
+CI/CD variables are applied to environments via the runner and can be set from the project's **Settings > CI/CD** page.
+
+The values are encrypted using [`aes-256-cbc`](https://en.wikipedia.org/wiki/Advanced_Encryption_Standard) and stored in the database.
+
+This data can only be decrypted with a valid [secrets file](../raketasks/backup_restore.md#when-the-secrets-file-is-lost).

doc/user/application_security/api_fuzzing/index.md

@@ -89,7 +89,7 @@ Follow these steps to configure API fuzzing in GitLab with an OpenAPI specificat
    amounts of fuzzing. We recommend that you start with the `Quick-10` profile. Testing with this
    profile completes quickly, allowing for easier configuration validation.
 
-   Provide the profile by adding the `FUZZAPI_PROFILE` variable to your `.gitlab-ci.yml` file,
+   Provide the profile by adding the `FUZZAPI_PROFILE` CI/CD variable to your `.gitlab-ci.yml` file,
    substituting `Quick-10` for the profile you choose:
 
    ```yaml
@@ -182,7 +182,7 @@ target API to test:
    amounts of fuzzing. We recommend that you start with the `Quick-10` profile. Testing with this
    profile completes quickly, allowing for easier configuration validation.
 
-   Provide the profile by adding the `FUZZAPI_PROFILE` variable to your `.gitlab-ci.yml` file,
+   Provide the profile by adding the `FUZZAPI_PROFILE` CI/CD variable to your `.gitlab-ci.yml` file,
    substituting `Quick-10` for the profile you choose:
 
    ```yaml
@@ -273,7 +273,7 @@ information about the target API to test:
    amounts of fuzzing. We recommend that you start with the `Quick-10` profile. Testing with this
    profile completes quickly, allowing for easier configuration validation.
 
-   Provide the profile by adding the `FUZZAPI_PROFILE` variable to your `.gitlab-ci.yml` file,
+   Provide the profile by adding the `FUZZAPI_PROFILE` CI/CD variable to your `.gitlab-ci.yml` file,
    substituting `Quick-10` for the profile you choose:
 
    ```yaml
@@ -337,8 +337,7 @@ provide a script that performs an authentication flow or calculates the token.
 [HTTP basic authentication](https://en.wikipedia.org/wiki/Basic_access_authentication)
 is an authentication method built in to the HTTP protocol and used in conjunction with
 [transport layer security (TLS)](https://en.wikipedia.org/wiki/Transport_Layer_Security).
-
-To use HTTP basic authentication, add these two variables to your `.gitlab-ci.yml` file:
+To use HTTP basic authentication, two CI/CD variables are added to your `.gitlab-ci.yml` file:
 
 - `FUZZAPI_HTTP_USERNAME`: The username for authentication.
 - `FUZZAPI_HTTP_PASSWORD`: The password for authentication.
@@ -358,7 +357,6 @@ variables:
   FUZZAPI_TARGET_URL: http://test-deployment/
   FUZZAPI_HTTP_USERNAME: testuser
   FUZZAPI_HTTP_PASSWORD: $TEST_API_PASSWORD
-
 ```
 
 #### Bearer Tokens
@@ -417,8 +415,10 @@ API fuzzing expects to receive a JSON file with the following structure:
 }
 ```
 
-You can provide this file to API fuzzing through the `FUZZAPI_OVERRIDES_FILE` variable, in your
-`.gitlab-ci.yml` file:
+This file can be generated by a prior stage and provided to API fuzzing through the
+`FUZZAPI_OVERRIDES_FILE` CI/CD variable.
+
+Set `FUZZAPI_OVERRIDES_FILE` in your `.gitlab-ci.yml` file:
 
 ```yaml
 include:
@@ -451,7 +451,7 @@ The script must create a JSON file containing the bearer token in a specific for
 }
 ```
 
-You must provide three variables, each set for correct operation:
+You must provide three CI/CD variables, each set for correct operation:
 
 - `FUZZAPI_OVERRIDES_FILE`: JSON file the provided command generates.
 - `FUZZAPI_OVERRIDES_CMD`: Command that generates the JSON file.
@@ -490,24 +490,24 @@ repository's root as `.gitlab-api-fuzzing.yml`.
 | Medium-50 | 50 |
 | Long-100  | 100 |
 
-### Available variables
+### Available CI/CD variables
 
-| Environment variable        | Description        |
-|-----------------------------|--------------------|
+| CI/CD variable                                       | Description        |
+|------------------------------------------------------|--------------------|
 | `FUZZAPI_VERSION`                                    | Specify API Fuzzing container version. Defaults to `latest`. |
 | `FUZZAPI_TARGET_URL`                                 | Base URL of API testing target. |
-| [`FUZZAPI_CONFIG`](#configuration-files) | API Fuzzing configuration file. Defaults to `.gitlab-apifuzzer.yml`. |
-| [`FUZZAPI_PROFILE`](#configuration-files) | Configuration profile to use during testing. Defaults to `Quick`. |
+|[`FUZZAPI_CONFIG`](#configuration-files)              | API Fuzzing configuration file. Defaults to `.gitlab-apifuzzer.yml`. |
+|[`FUZZAPI_PROFILE`](#configuration-files)             | Configuration profile to use during testing. Defaults to `Quick`. |
 | `FUZZAPI_REPORT`                                     | Scan report filename. Defaults to `gl-api_fuzzing-report.xml`. |
-| [`FUZZAPI_OPENAPI`](#openapi-specification) | OpenAPI specification file or URL. |
-| [`FUZZAPI_HAR`](#http-archive-har) | HTTP Archive (HAR) file. |
-| [`FUZZAPI_POSTMAN_COLLECTION`](#postman-collection) | Postman Collection file. |
-| [`FUZZAPI_OVERRIDES_FILE`](#overrides)     | Path to a JSON file containing overrides. |
-| [`FUZZAPI_OVERRIDES_ENV`](#overrides)      | JSON string containing headers to override. |
-| [`FUZZAPI_OVERRIDES_CMD`](#overrides)      | Overrides command. |
-| [`FUZZAPI_OVERRIDES_INTERVAL`](#overrides) | How often to run overrides command in seconds. Defaults to `0` (once). |
-| [`FUZZAPI_HTTP_USERNAME`](#http-basic-authentication) | Username for HTTP authentication. |
-| [`FUZZAPI_HTTP_PASSWORD`](#http-basic-authentication) | Password for HTTP authentication. |
+|[`FUZZAPI_OPENAPI`](#openapi-specification)           | OpenAPI specification file or URL. |
+|[`FUZZAPI_HAR`](#http-archive-har)                    | HTTP Archive (HAR) file. |
+|[`FUZZAPI_POSTMAN_COLLECTION`](#postman-collection)   | Postman Collection file. |
+|[`FUZZAPI_OVERRIDES_FILE`](#overrides)                | Path to a JSON file containing overrides. |
+|[`FUZZAPI_OVERRIDES_ENV`](#overrides)                 | JSON string containing headers to override. |
+|[`FUZZAPI_OVERRIDES_CMD`](#overrides)                 | Overrides command. |
+|[`FUZZAPI_OVERRIDES_INTERVAL`](#overrides)            | How often to run overrides command in seconds. Defaults to `0` (once). |
+|[`FUZZAPI_HTTP_USERNAME`](#http-basic-authentication) | Username for HTTP authentication. |
+|[`FUZZAPI_HTTP_PASSWORD`](#http-basic-authentication) | Password for HTTP authentication. |
 
 <!--|[`FUZZAPI_D_TARGET_IMAGE`](#target-container) |API target docker image |
 |[`FUZZAPI_D_TARGET_ENV`](#target-container)   |Docker environment options |
@@ -565,13 +565,12 @@ Example of setting both a header and cookie:
 }
 ```
 
-You can provide this JSON document as a file or environment variable. You may also provide a command
+You can provide this JSON document as a file or CI/CD variable. You may also provide a command
 to generate the JSON document. The command can run at intervals to support values that expire.
 
 #### Using a file
 
-To provide the override JSON as a file, set the `FUZZAPI_OVERRIDES_FILE` environment variable to the
-file. The file path is relative to the job's current working directory.
+To provide the overrides JSON as a file, the `FUZZAPI_OVERRIDES_FILE` CI/CD variable is set. The path is relative to the job current working directory.
 
 Here's an example `.gitlab-ci.yml`:
 
@@ -586,10 +585,10 @@ variables:
   FUZZAPI_OVERRIDES_FILE: output/api-fuzzing-overrides.json
 ```
 
-#### Using an environment variable
+#### Using a CI/CD variable
 
-To provide the override JSON as an environment variable, set the `FUZZAPI_OVERRIDES_ENV` variable to
-the JSON. You can also place the JSON as CI/CD variables that can be masked and protected.
+To provide the overrides JSON as a CI/CD variable, use the `FUZZAPI_OVERRIDES_ENV` variable.
+This allows you to place the JSON as variables that can be masked and protected.
 
 In this example `.gitlab-ci.yml`, the `FUZZAPI_OVERRIDES_ENV` variable is set directly to the JSON:
 
@@ -604,8 +603,8 @@ variables:
   FUZZAPI_OVERRIDES_ENV: '{"headers":{"X-API-Version":"2"}}'
 ```
 
-In this example `.gitlab-ci.yml`, the CI/CD variable `SECRET_OVERRIDES` provides the JSON. This is a
-[group or instance-level environment variable defined in the UI](../../../ci/variables/README.md#instance-level-cicd-variables):
+In this example `.gitlab-ci.yml`, the `SECRET_OVERRIDES` variable provides the JSON. This is a
+[group or instance level CI/CD variable defined in the UI](../../../ci/variables/README.md#instance-level-cicd-variables):
 
 ```yaml
 include:
@@ -621,9 +620,29 @@ variables:
 #### Using a command
 
 If the value must be generated or regenerated on expiration, you can provide a program or script for
-the API fuzzer to execute on a specified interval. To do this, follow the instructions in the
-section [Token has short expiration](#token-has-short-expiration),
-which uses the same three variables. The script creates the overrides JSON file as defined.
+the API fuzzer to execute on a specified interval. The provided script runs in an Alpine Linux
+container that has Python 3 and Bash installed. If the Python script requires additional packages,
+it must detect this and install the packages at runtime. The script creates the overrides JSON file
+as defined above.
+
+You must provide three CI/CD variables, each set for correct operation:
+
+- `FUZZAPI_OVERRIDES_FILE`: File generated by the provided command.
+- `FUZZAPI_OVERRIDES_CMD`: Command to generate JSON file.
+- `FUZZAPI_OVERRIDES_INTERVAL`: Interval in seconds to run command.
+
+```yaml
+include:
+  - template: API-Fuzzing.gitlab-ci.yml
+
+variables:
+  FUZZAPI_PROFILE: Quick
+  FUZZAPI_OPENAPI: test-api-specification.json
+  FUZZAPI_TARGET_URL: http://test-deployment/
+  FUZZAPI_OVERRIDES_FILE: output/api-fuzzing-overrides.json
+  FUZZAPI_OVERRIDES_CMD: renew_token.py
+  FUZZAPI_OVERRIDES_INTERVAL: 300
+```
 
 ### Header Fuzzing
 

doc/user/application_security/container_scanning/index.md

@@ -13,7 +13,7 @@ WARNING:
 GitLab 14.0 will replace its container scanning engine with Trivy. Currently, GitLab uses the open
 source Clair engine for container scanning. GitLab 13.9 deprecates Clair. This is not a hard
 breaking change, as customers who wish to continue to use Clair can do so by setting the
-`CS_MAJOR_VERSION` variable to version 3 (or earlier) in their `gitlab-ci.yaml` file. Since Clair is
+`CS_MAJOR_VERSION` CI/CD variable to version 3 (or earlier) in their `gitlab-ci.yaml` file. Since Clair is
 deprecated, however, note that GitLab will no longer update or maintain that scanning engine
 beginning in the 14.0 release. We advise customers to use the new default of Trivy beginning in
 GitLab 14.0 for regular updates and the latest features.
@@ -55,7 +55,7 @@ To enable container scanning in your pipeline, you need the following:
 - An image matching [Clair's list of supported distributions](https://quay.github.io/claircore/).
 - [Build and push](../../packages/container_registry/index.md#build-and-push-by-using-gitlab-cicd)
   your Docker image to your project's container registry. The name of the Docker image should use
-  the following [predefined environment variables](../../../ci/variables/predefined_variables.md):
+  the following [predefined CI/CD variables](../../../ci/variables/predefined_variables.md):
 
   ```plaintext
   $CI_REGISTRY_IMAGE/$CI_COMMIT_REF_SLUG:$CI_COMMIT_SHA
@@ -140,12 +140,12 @@ include:
 There may be cases where you want to customize how GitLab scans your containers. For example, you
 may want to enable more verbose output from Clair or Klar, access a Docker registry that requires
 authentication, and more. To change such settings, use the [`variables`](../../../ci/yaml/README.md#variables)
-parameter in your `.gitlab-ci.yml` to set [environment variables](#available-variables).
-The environment variables you set in your `.gitlab-ci.yml` overwrite those in
+parameter in your `.gitlab-ci.yml` to set [CI/CD variables](#available-variables).
+The variables you set in your `.gitlab-ci.yml` overwrite those in
 `Container-Scanning.gitlab-ci.yml`.
 
 This example [includes](../../../ci/yaml/README.md#include) the container scanning template and
-enables verbose output from Clair by setting the `CLAIR_OUTPUT` environment variable to `High`:
+enables verbose output from Clair by setting the `CLAIR_OUTPUT` variable to `High`:
 
 ```yaml
 include:
@@ -182,9 +182,9 @@ variables:
 #### Available variables
 
 You can [configure](#customizing-the-container-scanning-settings) container
-scanning by using the following environment variables:
+scanning by using the following CI/CD variables:
 
-| Environment Variable           | Default       | Description |
+| CI/CD Variable                 | Default       | Description |
 | ------------------------------ | ------------- | ----------- |
 | `ADDITIONAL_CA_CERT_BUNDLE`    | `""`          | Bundle of CA certs that you want to trust. See [Using a custom SSL CA certificate authority](#using-a-custom-ssl-ca-certificate-authority) for more details. |
 | `CLAIR_DB_CONNECTION_STRING`   | `postgresql://postgres:password@clair-vulnerabilities-db:5432/postgres?sslmode=disable&statement_timeout=60000` | 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`. |
@@ -228,7 +228,7 @@ instead.
 
 ### Using a custom SSL CA certificate authority
 
-You can use the `ADDITIONAL_CA_CERT_BUNDLE` environment variable to configure a custom SSL CA certificate authority, which is used to verify the peer when fetching Docker images from a registry which uses HTTPS. The `ADDITIONAL_CA_CERT_BUNDLE` value should contain the [text representation of the X.509 PEM public-key certificate](https://tools.ietf.org/html/rfc7468#section-5.1). For example, to configure this value in the `.gitlab-ci.yml` file, use the following:
+You can use the `ADDITIONAL_CA_CERT_BUNDLE` CI/CD variable to configure a custom SSL CA certificate authority, which is used to verify the peer when fetching Docker images from a registry which uses HTTPS. The `ADDITIONAL_CA_CERT_BUNDLE` value should contain the [text representation of the X.509 PEM public-key certificate](https://tools.ietf.org/html/rfc7468#section-5.1). For example, to configure this value in the `.gitlab-ci.yml` file, use the following:
 
 ```yaml
 container_scanning:
@@ -303,7 +303,7 @@ For details on saving and transporting Docker images as a file, see Docker's doc
 [`docker save`](https://docs.docker.com/engine/reference/commandline/save/), [`docker load`](https://docs.docker.com/engine/reference/commandline/load/),
 [`docker export`](https://docs.docker.com/engine/reference/commandline/export/), and [`docker import`](https://docs.docker.com/engine/reference/commandline/import/).
 
-#### Set container scanning CI job variables to use local container scanner analyzers
+#### Set container scanning CI/CD variables to use local container scanner analyzers
 
 1. [Override the container scanning template](#overriding-the-container-scanning-template) in your `.gitlab-ci.yml` file to refer to the Docker images hosted on your local Docker container registry:
 
@@ -360,13 +360,13 @@ image directly, follow these steps:
    docker run -p 5432:5432 -d --name clair-db arminc/clair-db:latest
    ```
 
-1. Configure an environment variable to point to your local machine's IP address (or insert your IP address instead of the `LOCAL_MACHINE_IP_ADDRESS` variable in the `CLAIR_DB_CONNECTION_STRING` in the next step):
+1. Configure a CI/CD variable to point to your local machine's IP address (or insert your IP address instead of the `LOCAL_MACHINE_IP_ADDRESS` variable in the `CLAIR_DB_CONNECTION_STRING` in the next step):
 
    ```shell
    export LOCAL_MACHINE_IP_ADDRESS=your.local.ip.address
    ```
 
-1. Run the analyzer's Docker image, passing the image and tag you want to analyze in the `CI_APPLICATION_REPOSITORY` and `CI_APPLICATION_TAG` environment variables:
+1. Run the analyzer's Docker image, passing the image and tag you want to analyze in the `CI_APPLICATION_REPOSITORY` and `CI_APPLICATION_TAG` variables:
 
    ```shell
    docker run \
@@ -463,7 +463,7 @@ Some vulnerabilities can be fixed by applying the solution that GitLab
 automatically generates.
 
 To enable remediation support, the scanning tool _must_ have access to the `Dockerfile` specified by
-the [`DOCKERFILE_PATH`](#available-variables) environment variable. To ensure that the scanning tool
+the [`DOCKERFILE_PATH`](#available-variables) CI/CD variable. To ensure that the scanning tool
 has access to this
 file, it's necessary to set [`GIT_STRATEGY: fetch`](../../../ci/runners/README.md#git-strategy) in
 your `.gitlab-ci.yml` file by following the instructions described in this document's

doc/user/application_security/coverage_fuzzing/index.md

@@ -119,10 +119,10 @@ You can configure this by passing `--regression=false/true` to `gitlab-cov-fuzz`
 shows. Also note that `gitlab-cov-fuzz` is a wrapper, so you can pass those arguments to configure
 any option available in the underlying fuzzing engine.
 
-### Available variables
+### Available CI/CD variables
 
-| Environment variable      | Description                                                        |
-|---------------------------|--------------------------------------------------------------------|
+| CI/CD variable        | Description                                                        |
+|-----------------------|--------------------------------------------------------------------|
 | `COVFUZZ_BRANCH`      | The branch for long-running fuzzing jobs. The default is `master`. |
 | `COVFUZZ_SEED_CORPUS` | Path to a seed corpus directory. The default is empty.             |
 | `COVFUZZ_URL_PREFIX`  | Path to the `gitlab-cov-fuzz` repository cloned for use with an offline environment. You should only change this when using an offline environment. The default value is `https://gitlab.com/gitlab-org/security-products/analyzers/gitlab-cov-fuzz/-/raw`. |

doc/user/application_security/dependency_scanning/analyzers.md

@@ -34,8 +34,8 @@ maintained by GitLab, but users can also integrate their own **custom images**.
 
 ## Official default analyzers
 
-Any custom change to the official analyzers can be achieved by using an
-[environment variable in your `.gitlab-ci.yml`](index.md#customizing-the-dependency-scanning-settings).
+Any custom change to the official analyzers can be achieved by using a
+[CI/CD variable in your `.gitlab-ci.yml`](index.md#customizing-the-dependency-scanning-settings).
 
 ### Using a custom Docker mirror
 

doc/user/application_security/index.md

@@ -57,7 +57,7 @@ see [configure SAST in the UI](sast/index.md#configure-sast-in-the-ui).
 ### Override the default registry base address
 
 By default, GitLab security scanners use `registry.gitlab.com/gitlab-org/security-products/analyzers` as the
-base address for Docker images. You can override this globally by setting the variable
+base address for Docker images. You can override this globally by setting the CI/CD variable
 `SECURE_ANALYZERS_PREFIX` to another location. Note that this affects all scanners at once.
 
 ## Security scanning tools
@@ -442,7 +442,7 @@ Read how to [operate the Secure scanners in an offline environment](offline_depl
 ## Using private Maven repositories
 
 If you have a private Apache Maven repository that requires login credentials,
-you can use the `MAVEN_CLI_OPTS` environment variable
+you can use the `MAVEN_CLI_OPTS` CI/CD variable
 to pass a username and password. You can set it under your project's settings
 so that your credentials aren't exposed in `.gitlab-ci.yml`.
 
@@ -451,7 +451,7 @@ If the username is `myuser` and the password is `verysecret` then you would
 under your project's settings:
 
 | Type     | Key              | Value |
-| ---- | --- | ----- |
+| -------- | ---------------- | ----- |
 | Variable | `MAVEN_CLI_OPTS` | `--settings mysettings.xml -Drepository.password=verysecret -Drepository.user=myuser` |
 
 ```xml
@@ -549,7 +549,7 @@ This is often followed by the [error `No files to upload`](../../ci/pipelines/jo
 and preceded by other errors or warnings that indicate why the JSON report wasn't generated. Please
 check the entire job log for such messages. If you don't find these messages, retry the failed job
 after setting `SECURE_LOG_LEVEL: "debug"` as a
-[custom environment variable](../../ci/variables/README.md#custom-cicd-variables).
+[custom CI/CD variable](../../ci/variables/README.md#custom-cicd-variables).
 This provides useful information to investigate further.
 
 ### Getting error message `sast job: config key may not be used with 'rules': only/except`

doc/user/application_security/offline_deployments/index.md

@@ -148,19 +148,19 @@ The project using the `Secure-Binaries.gitlab-ci.yml` template should now host a
 images and resources needed to run GitLab Security features.
 
 Next, you must tell the offline instance to use these resources instead of the default ones on
-GitLab.com. To do so, set the environment variable `SECURE_ANALYZERS_PREFIX` with the URL of the
+GitLab.com. To do so, set the CI/CD variable `SECURE_ANALYZERS_PREFIX` with the URL of the
 project [container registry](../../packages/container_registry/index.md).
 
 You can set this variable in the projects' `.gitlab-ci.yml`, or
-in the GitLab UI at the project or group level. See the [GitLab CI/CD environment variables page](../../../ci/variables/README.md#custom-cicd-variables)
+in the GitLab UI at the project or group level. See the [GitLab CI/CD variables page](../../../ci/variables/README.md#custom-cicd-variables)
 for more information.
 
 #### Variables
 
-The following table shows which variables you can use with the `Secure-Binaries.gitlab-ci.yml`
+The following table shows which CI/CD variables you can use with the `Secure-Binaries.gitlab-ci.yml`
 template:
 
-| VARIABLE                                  | Description                                   | Default value                     |
+| CI/CD variable                            | Description                                   | Default value                     |
 |-------------------------------------------|-----------------------------------------------|-----------------------------------|
 | `SECURE_BINARIES_ANALYZERS`               | Comma-separated list of analyzers to download | `"bandit, brakeman, gosec, and so on..."` |
 | `SECURE_BINARIES_DOWNLOAD_IMAGES`         | Used to disable jobs                          | `"true"`                          |
@@ -224,11 +224,11 @@ these steps:
    Before running AutoDevOps, follow the [above steps](#using-the-official-gitlab-template)
    to load those container images into the local container registry.
 
-1. Set the pipeline variable to ensure that AutoDevOps looks in the right place for those images.
+1. Set the CI/CD variable to ensure that AutoDevOps looks in the right place for those images.
    The AutoDevOps templates leverage the `SECURE_ANALYZERS_PREFIX` variable to identify the location
    of analyzer images. This variable is discussed above in [Using the secure bundle created](#using-the-secure-bundle-created).
    Ensure that you set this variable to the correct value for where you loaded the analyzer images.
-   You could consider doing this with a pipeline variable or by [modifying](../../../topics/autodevops/customize.md#customizing-gitlab-ciyml)
+   You could consider doing this with a project CI/CD variable or by [modifying](../../../topics/autodevops/customize.md#customizing-gitlab-ciyml)
    the `.gitlab-ci.yml` file directly.
 
 Once these steps are complete, GitLab has local copies of the Secure analyzers and is set up to use

doc/user/application_security/sast/analyzers.md

@@ -45,8 +45,8 @@ GitLab, but users can also integrate their own **custom images**.
 
 ## Official default analyzers
 
-Any custom change to the official analyzers can be achieved by using an
-[environment variable in your `.gitlab-ci.yml`](index.md#customizing-the-sast-settings).
+Any custom change to the official analyzers can be achieved by using a
+[CI/CD variable in your `.gitlab-ci.yml`](index.md#customizing-the-sast-settings).
 
 ### Using a custom Docker mirror
 

doc/user/application_security/secret_detection/index.md

@@ -87,7 +87,7 @@ Different features are available in different [GitLab tiers](https://about.gitla
 as shown in the following table:
 
 | Capability                                                      | In Free             | In Ultimate        |
-|:--------------------------------------------------------------------------|:--------------------|:-------------------|
+|:----------------------------------------------------------------|:--------------------|:-------------------|
 | [Configure Secret Detection Scanners](#configuration)           | **{check-circle}**  | **{check-circle}** |
 | [Customize Secret Detection Settings](#customizing-settings)    | **{check-circle}**  | **{check-circle}** |
 | View [JSON Report](../sast/index.md#reports-json-format)        | **{check-circle}**  | **{check-circle}** |
@@ -148,7 +148,7 @@ Third party cloud and SaaS providers can [express integration interest by fillin
 
 ### Customizing settings
 
-The Secret Detection scan settings can be changed through [environment variables](#available-variables)
+The Secret Detection scan settings can be changed through [CI/CD variables](#available-variables)
 by using the
 [`variables`](../../../ci/yaml/README.md#variables) parameter in `.gitlab-ci.yml`.
 
@@ -162,7 +162,7 @@ is no longer supported. When overriding the template, you must use [`rules`](../
 
 #### GIT_DEPTH
 
-The [`GIT_DEPTH` variable](../../../ci/runners/README.md#shallow-cloning) affects Secret Detection.
+The [`GIT_DEPTH` CI/CD variable](../../../ci/runners/README.md#shallow-cloning) affects Secret Detection.
 The Secret Detection analyzer relies on generating patches between commits to scan content for
 secrets. If you override the default, ensure the value is greater than 1. If the number of commits
 in an MR is greater than the GIT_DEPTH value, Secret Detection will [fail to detect secrets](#error-couldnt-run-the-gitleaks-command-exit-status-2).
@@ -170,7 +170,7 @@ in an MR is greater than the GIT_DEPTH value, Secret Detection will [fail to det
 #### Custom settings example
 
 In the following example, we include the Secret Detection template and at the same time we
-override the `secret_detection` job with the `SECRET_DETECTION_HISTORIC_SCAN` variable to `true`:
+override the `secret_detection` job with the `SECRET_DETECTION_HISTORIC_SCAN` CI/CD variable to `true`:
 
 ```yaml
 include:
@@ -186,10 +186,10 @@ the pipeline configuration, the last mention of the variable takes precedence.
 
 #### Available variables
 
-Secret Detection can be customized by defining available variables:
+Secret Detection can be customized by defining available CI/CD variables:
 
-| Environment variable    | Default value | Description |
-|-------------------------|---------------|-------------|
+| CI/CD variable                    | Default value | Description |
+|-----------------------------------|---------------|-------------|
 | `SECRET_DETECTION_COMMIT_FROM`    | -             | The commit a Gitleaks scan starts at. |
 | `SECRET_DETECTION_COMMIT_TO`      | -             | The commit a Gitleaks scan ends at. |
 | `SECRET_DETECTION_EXCLUDED_PATHS` | ""            | Exclude vulnerabilities from output based on the paths. This is a comma-separated list of patterns. Patterns can be globs, or file or folder paths (for example, `doc,spec` ). Parent directories also match patterns. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/225273) in GitLab 13.3. |
@@ -240,7 +240,7 @@ To create a custom ruleset:
 
 ### Logging level
 
-To control the verbosity of logs set the `SECURE_LOG_LEVEL` environment variable. Messages of this logging level or higher are output. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/10880) in GitLab 13.1.
+To control the verbosity of logs set the `SECURE_LOG_LEVEL` CI/CD variable. Messages of this logging level or higher are output. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/10880) in GitLab 13.1.
 
 From highest to lowest severity, the logging levels are:
 
@@ -255,7 +255,7 @@ From highest to lowest severity, the logging levels are:
 GitLab 12.11 introduced support for scanning the full history of a repository. This new functionality
 is particularly useful when you are enabling Secret Detection in a repository for the first time and you
 want to perform a full secret scan. Running a secret scan on the full history can take a long time,
-especially for larger repositories with lengthy Git histories. We recommend not setting this variable
+especially for larger repositories with lengthy Git histories. We recommend not setting this CI/CD variable
 as part of your normal job definition.
 
 A new configuration variable ([`SECRET_DETECTION_HISTORIC_SCAN`](../sast/#vulnerability-filters))
@@ -316,7 +316,7 @@ Support for custom certificate authorities was introduced in the following versi
 | -------- | ------- |
 | secrets | [v3.0.0](https://gitlab.com/gitlab-org/security-products/analyzers/secrets/-/releases/v3.0.0) |
 
-### Set Secret Detection CI job variables to use local Secret Detection analyzer
+### Set Secret Detection CI/CD variables to use local Secret Detection analyzer
 
 Add the following configuration to your `.gitlab-ci.yml` file. You must replace
 `SECURE_ANALYZERS_PREFIX` to refer to your local Docker container registry:
@@ -356,7 +356,7 @@ ERRO[2020-11-18T18:05:52Z] object not found
 [ERRO] [secrets] [2020-11-18T18:05:52Z] ▶ Gitleaks analysis failed: exit status 2
 ```
 
-To resolve the issue, set the [`GIT_DEPTH` variable](../../../ci/runners/README.md#shallow-cloning)
+To resolve the issue, set the [`GIT_DEPTH` CI/CD variable](../../../ci/runners/README.md#shallow-cloning)
 to a higher value. To apply this only to the Secret Detection job, the following can be added to
 your `.gitlab-ci.yml` file: