Commit 9de1a9b4 authored by Russell Dickenson's avatar Russell Dickenson

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

Change usage of variables terminology in Secure docs

See merge request gitlab-org/gitlab!54174
parents c867b405 63afbc51
......@@ -132,6 +132,7 @@ exceptions:
- SMTP
- SOC
- SOX
- SPDX
- SPF
- SQL
- SSD
......@@ -164,4 +165,5 @@ exceptions:
- XML
- XSS
- YAML
- ZAP
- ZIP
......@@ -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
......
---
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 -->
---
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).
......@@ -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
......
......@@ -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
......
......@@ -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`. |
......
......@@ -92,7 +92,7 @@ variables:
To use the latest version of the DAST template, include
`DAST.latest.gitlab-ci.yml` instead of `DAST.gitlab-ci.yml`.
See the CI [docs](../../../development/cicd/templates.md#latest-version)
See the CI/CD [documentation](../../../development/cicd/templates.md#latest-version)
on template versioning for more information.
Please note that the latest version may include breaking changes. Check the
......@@ -102,7 +102,7 @@ Please note that the latest version may include breaking changes. Check the
There are two ways to define the URL to be scanned by DAST:
1. Set the `DAST_WEBSITE` [variable](../../../ci/yaml/README.md#variables).
1. Set the `DAST_WEBSITE` [CI/CD variable](../../../ci/yaml/README.md#variables).
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
......@@ -177,7 +177,7 @@ authorization credentials. By default, the following headers are masked:
- `Set-Cookie` (values only).
- `Cookie` (values only).
Using the [`DAST_MASK_HTTP_HEADERS` variable](#available-variables), you can list the
Using the [`DAST_MASK_HTTP_HEADERS` CI/CD variable](#available-variables), you can list the
headers whose values you want masked. For details on how to mask headers, see
[Customizing the DAST settings](#customizing-the-dast-settings).
......@@ -192,7 +192,7 @@ of your application is likely not accessible without authentication. It is also
that you periodically confirm the scanner's authentication is still working as this tends to break over
time due to authentication changes to the application.
Create masked variables to pass the credentials that DAST uses.
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).
Note that the key of the username variable must be `DAST_USERNAME`
and the key of the password variable must be `DAST_PASSWORD`.
......@@ -252,7 +252,7 @@ and potentially damage them. You could even take down your production environmen
For that reason, you should use domain validation.
Domain validation is not required by default. It can be required by setting the
[environment variable](#available-variables) `DAST_FULL_SCAN_DOMAIN_VALIDATION_REQUIRED` to `"true"`.
[CI/CD variable](#available-variables) `DAST_FULL_SCAN_DOMAIN_VALIDATION_REQUIRED` to `"true"`.
```yaml
include:
......@@ -406,14 +406,14 @@ dast:
#### Full API scan
API scans support full scanning, which can be enabled by using the `DAST_FULL_SCAN_ENABLED`
environment variable. Domain validation is not supported for full API scans.
CI/CD variable. Domain validation is not supported for full API scans.
#### Host override
Specifications often define a host, which contains a domain name and a port. The
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` environment variable to override these values.
Use the `DAST_API_HOST_OVERRIDE` CI/CD variable to override these values.
For example, with a OpenAPI V3 specification containing:
......@@ -441,7 +441,7 @@ limitation in the ZAP OpenAPI extension.
#### Authentication using headers
Tokens in request headers are often used as a way to authenticate API requests.
You can achieve this by using the `DAST_REQUEST_HEADERS` environment variable.
You can achieve this by using the `DAST_REQUEST_HEADERS` CI/CD variable.
Headers are applied to every request DAST makes.
```yaml
......@@ -463,10 +463,10 @@ A URL scan allows you to specify which parts of a website are scanned by DAST.
URLs to scan can be specified by either of the following methods:
- Use `DAST_PATHS_FILE` environment variable to specify the name of a file containing the paths.
- Use `DAST_PATHS` environment variable to list the paths.
- Use `DAST_PATHS_FILE` CI/CD variable to specify the name of a file containing the paths.
- Use `DAST_PATHS` variable to list the paths.
##### Use DAST_PATHS_FILE environment variable
##### Use `DAST_PATHS_FILE` CI/CD variable
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/258825) in GitLab 13.6.
......@@ -478,7 +478,7 @@ page1.html
category/shoes/page1.html
```
To scan the URLs in that file, set the environment variable `DAST_PATHS_FILE` to the path of that file.
To scan the URLs in that file, set the CI/CD variable `DAST_PATHS_FILE` to the path of that file.
```yaml
include:
......@@ -501,12 +501,12 @@ dast:
DAST_PATHS_FILE: url_file.txt
```
##### Use DAST_PATHS environment variable
##### Use `DAST_PATHS` CI/CD variable
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/214120) in GitLab 13.4.
To specify the paths to scan in an environment variable, add a comma-separated list of the paths to the `DAST_PATHS`
environment variable. Note that you can only scan paths of a single host.
To specify the paths to scan in a CI/CD variable, add a comma-separated list of the paths to the `DAST_PATHS`
variable. Note that you can only scan paths of a single host.
```yaml
include:
......@@ -521,12 +521,12 @@ When using `DAST_PATHS` and `DAST_PATHS_FILE`, note the following:
- `DAST_WEBSITE` must be defined when using either `DAST_PATHS_FILE` or `DAST_PATHS`. The paths listed in either use `DAST_WEBSITE` to build the URLs to scan
- Spidering is disabled when `DAST_PATHS` or `DAST_PATHS_FILE` are defined
- `DAST_PATHS_FILE` and `DAST_PATHS` can not be used together
- The `DAST_PATHS` environment variable has a limit of about 130kb. If you have a list or paths
- The `DAST_PATHS` variable has a limit of about 130kb. If you have a list or paths
greater than this, use `DAST_PATHS_FILE`.
#### Full Scan
To perform a [full scan](#full-scan) on the listed paths, use the `DAST_FULL_SCAN_ENABLED` environment variable.
To perform a [full scan](#full-scan) on the listed paths, use the `DAST_FULL_SCAN_ENABLED` CI/CD variable.
### Customizing the DAST settings
......@@ -534,7 +534,7 @@ WARNING:
Beginning in GitLab 13.0, the use of [`only` and `except`](../../../ci/yaml/README.md#onlyexcept-basic)
is no longer supported. When overriding the template, you must use [`rules`](../../../ci/yaml/README.md#rules) instead.
The DAST settings can be changed through environment variables by using the
The DAST settings can be changed through CI/CD variables by using the
[`variables`](../../../ci/yaml/README.md#variables) parameter in `.gitlab-ci.yml`.
These variables are documented in [available variables](#available-variables).
......@@ -554,10 +554,10 @@ configuration, the last mention of the variable takes precedence.
### Available variables
DAST can be [configured](#customizing-the-dast-settings) using environment variables.
DAST can be [configured](#customizing-the-dast-settings) using CI/CD variables.
| Environment variable | Type | Description |
|-----------------------------| -----------|--------------------------------------------------------------------------------|
| CI/CD variable | Type | Description |
|------------------------------| --------|-------------|
| `SECURE_ANALYZERS_PREFIX` | URL | Set the Docker registry base address from which to download the analyzer. |
| `DAST_WEBSITE` | URL | The URL of the website to scan. `DAST_API_SPECIFICATION` must be specified if this is omitted. |
| `DAST_API_SPECIFICATION` | URL or string | The API specification to import. The specification can be hosted at a URL, or the name of a file present in the `/zap/wrk` directory. `DAST_WEBSITE` must be specified if this is omitted. |
......@@ -594,7 +594,7 @@ DAST can be [configured](#customizing-the-dast-settings) using environment varia
### DAST command-line options
Not all DAST configuration is available via environment variables. To find out all
Not all DAST configuration is available via CI/CD variables. To find out all
possible options, run the following configuration.
Available command-line options are printed to the job log:
......@@ -649,11 +649,11 @@ A DAST job has two executing processes:
- The ZAP server.
- A series of scripts that start, control and stop the ZAP server.
Debug mode of the scripts can be enabled by using the `DAST_DEBUG` environment variable. This can help when troubleshooting the job,
Debug mode of the scripts can be enabled by using the `DAST_DEBUG` CI/CD variable. This can help when troubleshooting the job,
and outputs statements indicating what percentage of the scan is complete.
For details on using variables, see [Overriding the DAST template](#customizing-the-dast-settings).
Debug mode of the ZAP server can be enabled using the `DAST_ZAP_LOG_CONFIGURATION` environment variable.
Debug mode of the ZAP server can be enabled using the `DAST_ZAP_LOG_CONFIGURATION` variable.
The following table outlines examples of values that can be set and the effect that they have on the output that is logged.
Multiple values can be specified, separated by semicolons.
......@@ -706,7 +706,7 @@ For details on saving and transporting Docker images as a file, see Docker's doc
[`docker export`](https://docs.docker.com/engine/reference/commandline/export/), and
[`docker import`](https://docs.docker.com/engine/reference/commandline/import/).
### Set DAST CI job variables to use local DAST analyzers
### Set DAST CI/CD job variables to use local DAST analyzers
Add the following configuration to your `.gitlab-ci.yml` file. You must replace `image` to refer to
the DAST Docker image hosted on your local Docker container registry:
......@@ -721,7 +721,7 @@ dast:
The DAST job should now use local copies of the DAST analyzers to scan your code and generate
security reports without requiring internet access.
Alternatively, you can use the variable `SECURE_ANALYZERS_PREFIX` to override the base registry address of the `dast` image.
Alternatively, you can use the CI/CD variable `SECURE_ANALYZERS_PREFIX` to override the base registry address of the `dast` image.
## On-demand scans
......@@ -1020,7 +1020,7 @@ vulnerabilities in your groups, projects and pipelines. Read more about the
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` environment variable as shown in the
`DAST_INCLUDE_ALPHA_VULNERABILITIES` CI/CD variable as shown in the
following configuration:
```yaml
......@@ -1068,7 +1068,7 @@ This results in the following error:
```
Fortunately, it's straightforward to increase the amount of memory available
for DAST by using the `DAST_ZAP_CLI_OPTIONS` environment variable:
for DAST by using the `DAST_ZAP_CLI_OPTIONS` CI/CD variable:
```yaml
include:
......
......@@ -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
......
......@@ -109,7 +109,7 @@ always take the latest dependency scanning artifact available.
### Customizing the dependency scanning settings
The dependency scanning settings can be changed through [environment variables](#available-variables) by using the
The dependency scanning settings can be changed through [CI/CD variables](#available-variables) by using the
[`variables`](../../../ci/yaml/README.md#variables) parameter in `.gitlab-ci.yml`.
For example:
......@@ -163,44 +163,44 @@ using environment variables.
The following variables allow configuration of global dependency scanning settings.
| Environment variable | Description |
| --------------------------------------- |------------ |
| `SECURE_ANALYZERS_PREFIX` | Override the name of the Docker registry providing the official default images (proxy). Read more about [customizing analyzers](analyzers.md). |
| `DS_DEFAULT_ANALYZERS` | Override the names of the official default images. Read more about [customizing analyzers](analyzers.md). |
| CI/CD variables | Description |
| ----------------------------|------------ |
| `ADDITIONAL_CA_CERT_BUNDLE` | Bundle of CA certs to trust. The bundle of certificates provided here is also used by other tools during the scanning process, such as `git`, `yarn`, or `npm`. See [Using a custom SSL CA certificate authority](#using-a-custom-ssl-ca-certificate-authority) for more details. |
| `DS_EXCLUDED_PATHS` | Exclude vulnerabilities from output based on the paths. A comma-separated list of patterns. Patterns can be globs, or file or folder paths (for example, `doc,spec`). Parent directories also match patterns. Default: `"spec, test, tests, tmp"` |
| `SECURE_LOG_LEVEL` | Set the minimum logging level. Messages of this logging level or higher are output. From highest to lowest severity, the logging levels are: `fatal`, `error`, `warn`, `info`, `debug`. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/10880) in GitLab 13.1. Default: `info` |
| `DS_DEFAULT_ANALYZERS` | Override the names of the official default images. Read more about [customizing analyzers](analyzers.md). |
| `DS_EXCLUDED_PATHS` | Exclude vulnerabilities from output based on the paths. A comma-separated list of patterns. Patterns can be globs, or file or folder paths (for example, `doc,spec`). Parent directories also match patterns. Default: `"spec, test, tests, tmp"`. |
| `SECURE_ANALYZERS_PREFIX` | Override the name of the Docker registry providing the official default images (proxy). Read more about [customizing analyzers](analyzers.md). |
| `SECURE_LOG_LEVEL` | Set the minimum logging level. Messages of this logging level or higher are output. From highest to lowest severity, the logging levels are: `fatal`, `error`, `warn`, `info`, `debug`. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/10880) in GitLab 13.1. Default: `info`. |
#### Configuring specific analyzers used by dependency scanning
The following variables are used for configuring specific analyzers (used for a specific language/framework).
| Environment variable | Analyzer | Default | Description |
| --------------------------------------- | ------------------ | ---------------------------- |------------ |
| CI/CD variable | Analyzer | Default | Description |
| ------------------------------------ | ------------------ | ---------------------------- |------------ |
| `BUNDLER_AUDIT_UPDATE_DISABLED` | `bundler-audit` | `"false"` | Disable automatic updates for the `bundler-audit` analyzer. Use if you're running dependency scanning in an offline, air-gapped 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`. |
| `GEMNASIUM_DB_LOCAL_PATH` | `gemnasium` | `/gemnasium-db` | Path to local Gemnasium database. |
| `GEMNASIUM_DB_REMOTE_URL` | `gemnasium` | `https://gitlab.com/gitlab-org/security-products/gemnasium-db.git` | Repository URL for fetching the Gemnasium database. |
| `GEMNASIUM_DB_REF_NAME` | `gemnasium` | `master` | Branch name for remote repository database. `GEMNASIUM_DB_REMOTE_URL` is required. |
| `DS_REMEDIATE` | `gemnasium` | `"true"` | Enable automatic remediation of vulnerable dependencies. |
| `DS_JAVA_VERSION` | `gemnasium-maven` | `11` | Version of Java. Available versions: `8`, `11`, `13`, `14`. Maven and Gradle use the Java version specified by this value. |
| `MAVEN_CLI_OPTS` | `gemnasium-maven` | `"-DskipTests --batch-mode"` | List of command line arguments that are passed to `maven` by the analyzer. See an example for [using private repositories](../index.md#using-private-maven-repositories). |
| `GRADLE_CLI_OPTS` | `gemnasium-maven` | | List of command line arguments that are passed to `gradle` by the analyzer. |
| `SBT_CLI_OPTS` | `gemnasium-maven` | | List of command-line arguments that the analyzer passes to `sbt`. |
| `PIP_INDEX_URL` | `gemnasium-python` | `https://pypi.org/simple` | Base URL of Python Package Index. |
| `PIP_EXTRA_INDEX_URL` | `gemnasium-python` | | Array of [extra URLs](https://pip.pypa.io/en/stable/reference/pip_install/#cmdoption-extra-index-url) of package indexes to use in addition to `PIP_INDEX_URL`. Comma-separated. |
| `PIP_REQUIREMENTS_FILE` | `gemnasium-python` | | Pip requirements file to be scanned. |
| `DS_PIP_VERSION` | `gemnasium-python` | | Force the install of a specific pip version (example: `"19.3"`), otherwise the pip installed in the Docker image is used. ([Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/12811) in GitLab 12.7) |
| `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, [removed](https://www.python.org/doc/sunset-python-2/) in GitLab 13.7)|
| `DS_JAVA_VERSION` | `gemnasium-maven` | `11` | Version of Java. Available versions: `8`, `11`, `13`, `14`. Maven and Gradle use the Java version specified by this value. |
| `MAVEN_CLI_OPTS` | `gemnasium-maven` | `"-DskipTests --batch-mode"` | List of command line arguments that are passed to `maven` by the analyzer. See an example for [using private repositories](../index.md#using-private-maven-repositories). |
| `GRADLE_CLI_OPTS` | `gemnasium-maven` | | List of command line arguments that are passed to `gradle` by the analyzer. |
| `SBT_CLI_OPTS` | `gemnasium-maven` | | List of command-line arguments that the analyzer passes to `sbt`. |
| `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_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. Note that if the URL hosting the data file uses a custom SSL certificate, for example in an offline installation, you can pass the certificate in the `ADDITIONAL_CA_CERT_BUNDLE` environment variable. |
| `RETIREJS_NODE_ADVISORY_DB` | `retire.js` | `https://raw.githubusercontent.com/RetireJS/retire.js/master/repository/npmrepository.json` | Path or URL to `retire.js` node vulnerability data file. Note that if the URL hosting the data file uses a custom SSL certificate, for example in an offline installation, you can pass the certificate in the `ADDITIONAL_CA_CERT_BUNDLE` environment variable. |
| `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, [removed](https://www.python.org/doc/sunset-python-2/) in GitLab 13.7). |
| `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. Note that if the URL hosting the data file uses a custom SSL certificate, for example in an offline installation, you can pass the certificate in the `ADDITIONAL_CA_CERT_BUNDLE` variable. |
| `RETIREJS_NODE_ADVISORY_DB` | `retire.js` | `https://raw.githubusercontent.com/RetireJS/retire.js/master/repository/npmrepository.json` | Path or URL to `retire.js` node vulnerability data file. Note that if the URL hosting the data file uses a custom SSL certificate, for example in an offline installation, you can pass the certificate in the `ADDITIONAL_CA_CERT_BUNDLE` variable. |
| `RETIREJS_ADVISORY_DB_INSECURE` | `retire.js` | `false` | Enable fetching remote JS and Node vulnerability data files (defined by the `RETIREJS_JS_ADVISORY_DB` and `RETIREJS_NODE_ADVISORY_DB` variables) from hosts using an insecure or self-signed SSL (TLS) certificate. |
### 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. 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. 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
variables:
......@@ -217,7 +217,7 @@ The `ADDITIONAL_CA_CERT_BUNDLE` value can also be configured as a [custom variab
### Using private Maven repositories
If your private Maven repository requires login credentials,
you can use the `MAVEN_CLI_OPTS` environment variable.
you can use the `MAVEN_CLI_OPTS` CI/CD variable.
Read more on [how to use private Maven repositories](../index.md#using-private-maven-repositories).
......@@ -386,7 +386,7 @@ Here are the requirements for using dependency scanning in an offline environmen
- GitLab Runner with the [`docker` or `kubernetes` executor](#requirements).
- Docker Container Registry with locally available copies of dependency scanning [analyzer](https://gitlab.com/gitlab-org/security-products/analyzers) images.
- If you have a limited access environment you need to allow access, such as using a proxy, to the advisory database: `https://gitlab.com/gitlab-org/security-products/gemnasium-db.git`.
If you are unable to permit access to `https://gitlab.com/gitlab-org/security-products/gemnasium-db.git` you must host an offline copy of this `git` repository and set the `GEMNASIUM_DB_REMOTE_URL` variable to the URL of this repository. For more information on configuration variables, see [Dependency Scanning](#configuring-dependency-scanning).
If you are unable to permit access to `https://gitlab.com/gitlab-org/security-products/gemnasium-db.git` you must host an offline copy of this `git` repository and set the `GEMNASIUM_DB_REMOTE_URL` CI/CD variable to the URL of this repository. For more information on configuration variables, see [Dependency Scanning](#configuring-dependency-scanning).
This advisory database is constantly being updated, so you must periodically sync your local copy with GitLab.
......@@ -436,7 +436,7 @@ Support for custom certificate authorities was introduced in the following versi
| `retire.js` | [v2.4.0](https://gitlab.com/gitlab-org/security-products/analyzers/retire.js/-/releases/v2.4.0) |
| `bundler-audit` | [v2.4.0](https://gitlab.com/gitlab-org/security-products/analyzers/bundler-audit/-/releases/v2.4.0) |
### Set dependency scanning CI job variables to use local dependency scanning analyzers
### Set dependency scanning CI/CD job variables to use local dependency scanning analyzers
Add the following configuration to your `.gitlab-ci.yml` file. You must change the value of
`SECURE_ANALYZERS_PREFIX` to refer to your local Docker container registry. You must also change the
......
......@@ -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`
......
......@@ -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
......
......@@ -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
......
......@@ -190,14 +190,15 @@ page:
1. If the project does not have a `.gitlab-ci.yml` file, click **Enable** in the Static Application Security Testing (SAST) row, otherwise click **Configure**.
1. Enter the custom SAST values.
Custom values are stored in the `.gitlab-ci.yml` file. For variables not in the SAST Configuration page, their values are left unchanged. Default values are inherited from the GitLab SAST template.
Custom values are stored in the `.gitlab-ci.yml` file. For CI/CD variables not in the SAST Configuration page, their values are left unchanged. Default values are inherited from the GitLab SAST template.
1. Optionally, expand the **SAST analyzers** section, select individual [SAST analyzers](analyzers.md) and enter custom analyzer values.
1. Click **Create Merge Request**.
1. Review and merge the merge request.
### Customizing the SAST settings
The SAST settings can be changed through [environment variables](#available-variables)
The SAST settings can be changed through [CI/CD variables](#available-variables)
by using the
[`variables`](../../../ci/yaml/README.md#variables) parameter in `.gitlab-ci.yml`.
In the following example, we include the SAST template and at the same time we
......@@ -330,18 +331,18 @@ To create a custom ruleset:
value = "gosec-config.json"
```
### Using environment variables to pass credentials for private repositories
### Using CI/CD variables to pass credentials for private repositories
Some analyzers require downloading the project's dependencies in order to
perform the analysis. In turn, such dependencies may live in private Git
repositories and thus require credentials like username and password to download them.
Depending on the analyzer, such credentials can be provided to
it via [custom environment variables](#custom-environment-variables).
it via [custom CI/CD variables](#custom-cicd-variables).
#### Using a variable to pass username and password to a private Maven repository
#### Using a CI/CD variable to pass username and password to a private Maven repository
If your private Maven repository requires login credentials,
you can use the `MAVEN_CLI_OPTS` environment variable.
you can use the `MAVEN_CLI_OPTS` CI/CD variable.
Read more on [how to use private Maven repositories](../index.md#using-private-maven-repositories).
......@@ -369,7 +370,7 @@ a `before_script` execution to prepare your scan job.
To pass your project's dependencies as artifacts, the dependencies must be included
in the project's working directory and specified using the `artifacts:path` configuration.
If all dependencies are present, the `COMPILE=false` variable can be provided to the
If all dependencies are present, the `COMPILE=false` CI/CD variable can be provided to the
analyzer and compilation is skipped:
```yaml
......@@ -409,7 +410,7 @@ can use `MAVEN_REPO_PATH`. See
### Available variables
SAST can be [configured](#customizing-the-sast-settings) using environment variables.
SAST can be [configured](#customizing-the-sast-settings) using CI/CD variables.
#### Logging level
......@@ -445,9 +446,9 @@ The `ADDITIONAL_CA_CERT_BUNDLE` value can also be configured as a [custom variab
#### Docker images
The following are Docker image-related variables.
The following are Docker image-related CI/CD variables.
| Environment variable | Description |
| CI/CD variable | Description |
|---------------------------|---------------------------------------------------------------------------------------------------------------------------------------|
| `SECURE_ANALYZERS_PREFIX` | Override the name of the Docker registry providing the default images (proxy). Read more about [customizing analyzers](analyzers.md). |
| `SAST_ANALYZER_IMAGE_TAG` | **DEPRECATED:** Override the Docker tag of the default images. Read more about [customizing analyzers](analyzers.md). |
......@@ -458,8 +459,8 @@ The following are Docker image-related variables.
Some analyzers make it possible to filter out vulnerabilities under a given threshold.
| Environment variable | Default value | Description |
|-------------------------------|--------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| CI/CD variable | Default value | Description |
|------------------------------|--------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| `SAST_EXCLUDED_PATHS` | `spec, test, tests, tmp` | 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. You might need to exclude temporary directories used by your build tool as these can generate false positives. |
| `SEARCH_MAX_DEPTH` | 4 | SAST searches the repository to detect the programming languages used, and selects the matching analyzers. Set the value of `SEARCH_MAX_DEPTH` to specify how many directory levels the search phase should span. After the analyzers have been selected, the _entire_ repository is analyzed. |
| `SAST_BANDIT_EXCLUDED_PATHS` | | Comma-separated list of paths to exclude from scan. Uses Python's [`fnmatch` syntax](https://docs.python.org/2/library/fnmatch.html); For example: `'*/tests/*, */venv/*'` |
......@@ -469,15 +470,15 @@ Some analyzers make it possible to filter out vulnerabilities under a given thre
#### Analyzer settings
Some analyzers can be customized with environment variables.
Some analyzers can be customized with CI/CD variables.
| Environment variable | Analyzer | Description |
|---------------------------------------|----------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| CI/CD variable | Analyzer | Description |
|-----------------------------|------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| `SCAN_KUBERNETES_MANIFESTS` | Kubesec | Set to `"true"` to scan Kubernetes manifests. |
| `KUBESEC_HELM_CHARTS_PATH` | Kubesec | Optional path to Helm charts that `helm` uses to generate a Kubernetes manifest that `kubesec` scans. If dependencies are defined, `helm dependency build` should be ran in a `before_script` to fetch the necessary dependencies. |
| `KUBESEC_HELM_OPTIONS` | Kubesec | Additional arguments for the `helm` executable. |
| `COMPILE` | SpotBugs | Set to `false` to disable project compilation and dependency fetching. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/195252) in GitLab 13.1. |
| `ANT_HOME` | SpotBugs | The `ANT_HOME` environment variable. |
| `ANT_HOME` | SpotBugs | The `ANT_HOME` variable. |
| `ANT_PATH` | SpotBugs | Path to the `ant` executable. |
| `GRADLE_PATH` | SpotBugs | Path to the `gradle` executable. |
| `JAVA_OPTS` | SpotBugs | Additional arguments for the `java` executable. |
......@@ -492,12 +493,12 @@ Some analyzers can be customized with environment variables.
| `PHPCS_SECURITY_AUDIT_PHP_EXTENSIONS` | phpcs-security-audit | Comma separated list of additional PHP Extensions. |
| `SAST_DISABLE_BABEL` | NodeJsScan | Disable Babel processing for the NodeJsScan scanner. Set to `true` to disable Babel processing. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/33065) in GitLab 13.2. |
#### Custom environment variables
#### Custom CI/CD variables
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/18193) in GitLab Ultimate 12.5.
In addition to the aforementioned SAST configuration variables,
all [custom CI/CD variables](../../../ci/variables/README.md#custom-cicd-variables) are propagated
In addition to the aforementioned SAST configuration CI/CD variables,
all [custom variables](../../../ci/variables/README.md#custom-cicd-variables) are propagated
to the underlying SAST analyzer images if
[the SAST vendored template](#configuration) is used.
......@@ -705,7 +706,7 @@ Support for custom certificate authorities was introduced in the following versi
| `sobelow` | [v2.2.0](https://gitlab.com/gitlab-org/security-products/analyzers/sobelow/-/releases/v2.2.0) |
| `spotbugs` | [v2.7.1](https://gitlab.com/gitlab-org/security-products/analyzers/spotbugs/-/releases/v2.7.1) |
### Set SAST CI job variables to use local SAST analyzers
### Set SAST CI/CD variables to use local SAST analyzers
Add the following configuration to your `.gitlab-ci.yml` file. You must replace
`SECURE_ANALYZERS_PREFIX` to refer to your local Docker container registry:
......
......@@ -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:
......
......@@ -118,7 +118,7 @@ always take the latest License Compliance artifact available. Behind the scenes,
[GitLab License Compliance Docker image](https://gitlab.com/gitlab-org/security-products/analyzers/license-finder)
is used to detect the languages/frameworks and in turn analyzes the licenses.
The License Compliance settings can be changed through [environment variables](#available-variables) by using the
The License Compliance settings can be changed through [CI/CD variables](#available-variables) by using the
[`variables`](../../../ci/yaml/README.md#variables) parameter in `.gitlab-ci.yml`.
### When License Compliance runs
......@@ -128,9 +128,9 @@ wait for other stages to complete.
### Available variables
License Compliance can be configured using environment variables.
License Compliance can be configured using CI/CD variables.
| Environment variable | Required | Description |
| CI/CD variable | Required | Description |
|-----------------------------|----------|-------------|
| `ADDITIONAL_CA_CERT_BUNDLE` | no | Bundle of trusted CA certificates (currently supported in Pip, Pipenv, Maven, Gradle, Yarn, and npm projects). |
| `ASDF_JAVA_VERSION` | no | Version of Java to use for the scan. |
......@@ -154,7 +154,7 @@ The `license_management` image already embeds many auto-detection scripts, langu
and packages. Nevertheless, it's almost impossible to cover all cases for all projects.
That's why sometimes it's necessary to install extra packages, or to have extra steps
in the project automated setup, like the download and installation of a certificate.
For that, a `LICENSE_MANAGEMENT_SETUP_CMD` environment variable can be passed to the container,
For that, a `LICENSE_MANAGEMENT_SETUP_CMD` CI/CD variable can be passed to the container,
with the required commands to run before the license detection.
If present, this variable overrides the setup step necessary to install all the packages
......@@ -195,7 +195,7 @@ license_scanning:
### Configuring Maven projects
The License Compliance tool provides a `MAVEN_CLI_OPTS` environment variable which can hold
The License Compliance tool provides a `MAVEN_CLI_OPTS` CI/CD variable which can hold
the command line arguments to pass to the `mvn install` command which is executed under the hood.
Feel free to use it for the customization of Maven execution. For example:
......@@ -220,7 +220,7 @@ If you still need to run tests during `mvn install`, add `-DskipTests=false` to
#### Using private Maven repositories
If you have a private Maven repository which requires login credentials,
you can use the `MAVEN_CLI_OPTS` environment variable.
you can use the `MAVEN_CLI_OPTS` CI/CD variable.
Read more on [how to use private Maven repositories](../../application_security/index.md#using-private-maven-repositories).
......@@ -248,7 +248,7 @@ generate a key store file, see the
License Compliance uses Python 3.8 and pip 19.1 by default.
If your project requires Python 2, you can switch to Python 2.7 and pip 10.0
by setting the `LM_PYTHON_VERSION` environment variable to `2`.
by setting the `LM_PYTHON_VERSION` CI/CD variable to `2`.
```yaml
include:
......@@ -262,11 +262,11 @@ license_scanning:
### Custom root certificates for Python
You can supply a custom root certificate to complete TLS verification by using the
`ADDITIONAL_CA_CERT_BUNDLE` [environment variable](#available-variables).
`ADDITIONAL_CA_CERT_BUNDLE` [CI/CD variable](#available-variables).
#### Using private Python repositories
If you have a private Python repository you can use the `PIP_INDEX_URL` [environment variable](#available-variables)
If you have a private Python repository you can use the `PIP_INDEX_URL` [CI/CD variable](#available-variables)
to specify its location.
### Configuring npm projects
......@@ -289,7 +289,7 @@ registry = https://npm.example.com
#### Custom root certificates for npm
You can supply a custom root certificate to complete TLS verification by using the
`ADDITIONAL_CA_CERT_BUNDLE` [environment variable](#available-variables).
`ADDITIONAL_CA_CERT_BUNDLE` [CI/CD variable](#available-variables).
To disable TLS verification you can provide the [`strict-ssl`](https://docs.npmjs.com/using-npm/config/#strict-ssl)
setting.
......@@ -320,7 +320,7 @@ npmRegistryServer: "https://npm.example.com"
#### Custom root certificates for Yarn
You can supply a custom root certificate to complete TLS verification by using the
`ADDITIONAL_CA_CERT_BUNDLE` [environment variable](#available-variables).
`ADDITIONAL_CA_CERT_BUNDLE` [CI/CD variable](#available-variables).
### Configuring Bower projects
......@@ -344,7 +344,7 @@ For example:
#### Custom root certificates for Bower
You can supply a custom root certificate to complete TLS verification by using the
`ADDITIONAL_CA_CERT_BUNDLE` [environment variable](#available-variables), or by
`ADDITIONAL_CA_CERT_BUNDLE` [CI/CD variable](#available-variables), or by
specifying a `ca` setting in a [`.bowerrc`](https://bower.io/docs/config/#bowerrc-specification)
file.
......@@ -365,9 +365,9 @@ source "https://gems.example.com"
#### Custom root certificates for Bundler
You can supply a custom root certificate to complete TLS verification by using the
`ADDITIONAL_CA_CERT_BUNDLE` [environment variable](#available-variables), or by
`ADDITIONAL_CA_CERT_BUNDLE` [CI/CD variable](#available-variables), or by
specifying a [`BUNDLE_SSL_CA_CERT`](https://bundler.io/v2.0/man/bundle-config.1.html)
[environment variable](../../../ci/variables/README.md#custom-cicd-variables)
[variable](../../../ci/variables/README.md#custom-cicd-variables)
in the job definition.
### Configuring Cargo projects
......@@ -389,9 +389,9 @@ my-registry = { index = "https://my-intranet:8080/git/index" }
To supply a custom root certificate to complete TLS verification, do one of the following:
- Use the `ADDITIONAL_CA_CERT_BUNDLE` [environment variable](#available-variables).
- Use the `ADDITIONAL_CA_CERT_BUNDLE` [CI/CD variable](#available-variables).
- Specify a [`CARGO_HTTP_CAINFO`](https://doc.rust-lang.org/cargo/reference/environment-variables.html)
[environment variable](../../../ci/variables/README.md#custom-cicd-variables)
[variable](../../../ci/variables/README.md#custom-cicd-variables)
in the job definition.
### Configuring Composer projects
......@@ -422,9 +422,9 @@ For example:
#### Custom root certificates for Composer
You can supply a custom root certificate to complete TLS verification by using the
`ADDITIONAL_CA_CERT_BUNDLE` [environment variable](#available-variables), or by
`ADDITIONAL_CA_CERT_BUNDLE` [CI/CD variable](#available-variables), or by
specifying a [`COMPOSER_CAFILE`](https://getcomposer.org/doc/03-cli.md#composer-cafile)
[environment variable](../../../ci/variables/README.md#custom-cicd-variables)
[variable](../../../ci/variables/README.md#custom-cicd-variables)
in the job definition.
### Configuring Conan projects
......@@ -487,7 +487,7 @@ example:
}
```
If credentials are required to authenticate then you can configure a [protected variable](../../../ci/variables/README.md#protect-a-custom-variable)
If credentials are required to authenticate then you can configure a [protected CI/CD variable](../../../ci/variables/README.md#protect-a-custom-variable)
following the naming convention described in the [`CONAN_LOGIN_USERNAME` documentation](https://docs.conan.io/en/latest/reference/env_vars.html#conan-login-username-conan-login-username-remote-name).
#### Custom root certificates for Conan
......@@ -496,14 +496,14 @@ You can provide custom certificates by adding a `.conan/cacert.pem` file to the
setting [`CA_CERT_PATH`](https://docs.conan.io/en/latest/reference/env_vars.html#conan-cacert-path)
to `.conan/cacert.pem`.
If you specify the `ADDITIONAL_CA_CERT_BUNDLE` [environment variable](#available-variables), this
If you specify the `ADDITIONAL_CA_CERT_BUNDLE` [CI/CD variable](#available-variables), this
variable's X.509 certificates are installed in the Docker image's default trust store and Conan is
configured to use this as the default `CA_CERT_PATH`.
### Configuring Go projects
To configure [Go modules](https://github.com/golang/go/wiki/Modules)
based projects, specify [environment variables](https://golang.org/pkg/cmd/go/#hdr-Environment_variables)
based projects, specify [CI/CD variables](https://golang.org/pkg/cmd/go/#hdr-Environment_variables)
in the `license_scanning` job's [variables](#available-variables) section in `.gitlab-ci.yml`.
If a project has [vendored](https://golang.org/pkg/cmd/go/#hdr-Vendor_Directories) its modules,
......@@ -553,7 +553,7 @@ For example:
#### Custom root certificates for NuGet
You can supply a custom root certificate to complete TLS verification by using the
`ADDITIONAL_CA_CERT_BUNDLE` [environment variable](#available-variables).
`ADDITIONAL_CA_CERT_BUNDLE` [CI/CD variable](#available-variables).
### Migration from `license_management` to `license_scanning`
......@@ -640,7 +640,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 License Compliance CI job variables to use local License Compliance analyzers
### Set License Compliance CI/CD variables to use local License Compliance analyzers
Add the following configuration to your `.gitlab-ci.yml` file. You must replace `image` to refer to
the License Compliance Docker image hosted on your local Docker container registry:
......@@ -776,7 +776,7 @@ nodejs 12.16.3
ruby 2.7.2
```
The next example shows how to activate the same versions of the tools mentioned above by using environment variables defined in your
The next example shows how to activate the same versions of the tools mentioned above by using CI/CD variables defined in your
project's `.gitlab-ci.yml` file.
```yaml
......@@ -789,7 +789,7 @@ license_scanning:
ASDF_RUBY_VERSION: '2.7.2'
```
A full list of variables can be found in [environment variables](#available-variables).
A full list of variables can be found in [CI/CD variables](#available-variables).
To find out what tools are pre-installed in the `license_scanning` Docker image use the following command:
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment