Skip to content

G
gitlab-ce
Commit 3d1be386 authored by Achilleas Pipinellis's avatar Achilleas Pipinellis
Browse files
Options

Merge branch 'docs/secure-redirects' into 'master' 

Redirect old Secure docs to new location

Closes #11109

See merge request gitlab-org/gitlab-ee!10982
parents 52477ff5 59ad8019
Hide whitespace changes
Inline Side-by-side
Showing with 96 additions and 1487 deletions
doc/README.md
View file @ 3d1be386
......@@ -351,15 +351,15 @@ high-level view on projects and groups, and start remediation processes when nee
The following documentation relates to the DevOps **Secure** stage:
| Monitor Topics | Description |
|:--------------------------------------------------------------------------------------------------|:-----------------------------------------------------------------------|
| [Container Scanning](user/project/merge_requests/container_scanning.md) **[ULTIMATE]** | Use Clair to scan docker images for known vulnerabilities. |
| [Dependency Scanning](user/project/merge_requests/dependency_scanning.md) **[ULTIMATE]** | Analyze your dependencies for known vulnerabilities. |
| [Dynamic Application Security Testing (DAST)](user/project/merge_requests/dast.md) **[ULTIMATE]** | Analyze running web applications for known vulnerabilities. |
| [Group Security Dashboard](user/group/security_dashboard/index.md) **[ULTIMATE]** | View vulnerabilities in all the projects in a group and its subgroups. |
| [License Management](user/project/merge_requests/license_management.md) **[ULTIMATE]** | Search your project's dependencies for their licenses. |
| [Project Security Dashboard](user/project/security_dashboard.md) **[ULTIMATE]** | View the latest security reports for your project. |
| [Static Application Security Testing (SAST)](user/project/merge_requests/sast.md) **[ULTIMATE]** | Analyze source code for known vulnerabilities. |
| Secure Topics | Description |
|:------------------------------------------------------------------------------------------------------|:-----------------------------------------------------------------------|
| [Container Scanning](user/application_security/container_scanning/index.md) **[ULTIMATE]** | Use Clair to scan docker images for known vulnerabilities. |
| [Dependency Scanning](user/application_security/dependency_scanning/index.md) **[ULTIMATE]** | Analyze your dependencies for known vulnerabilities. |
| [Dynamic Application Security Testing (DAST)](user/application_security/dast/index.md) **[ULTIMATE]** | Analyze running web applications for known vulnerabilities. |
| [Group Security Dashboard](user/application_security/security_dashboard/index.md) **[ULTIMATE]** | View vulnerabilities in all the projects in a group and its subgroups. |
| [License Management](user/application_security/license_management/index.md) **[ULTIMATE]** | Search your project's dependencies for their licenses. |
| [Project Security Dashboard](user/application_security/security_dashboard/index.md) **[ULTIMATE]** | View the latest security reports for your project. |
| [Static Application Security Testing (SAST)](user/application_security/sast/index.md) **[ULTIMATE]** | Analyze source code for known vulnerabilities. |
## Subscribe to GitLab
......
doc/ci/examples/container_scanning.md
View file @ 3d1be386
# Container Scanning with GitLab CI/CD **[ULTIMATE]**
---
redirect_to: '../../user/application_security/container_scanning/index.md'
---
You can check your Docker images (or more precisely the containers) for known
vulnerabilities by using [Clair](https://github.com/coreos/clair) and
[clair-scanner](https://github.com/arminc/clair-scanner), two open source tools
for Vulnerability Static Analysis for containers.
These examples show how to run Container Scanning on your Docker image by using GitLab CI/CD.
CAUTION: **Caution:**
Starting with GitLab 11.5, Container Scanning feature is licensed under the name `container_scanning`.
While the old name `sast_container` is still maintained, it has been deprecated with GitLab 11.5 and
may be removed in next major release, GitLab 12.0. You are advised to update your current `.gitlab-ci.yml`
configuration to reflect that change if you are using the `$GITLAB_FEATURES` environment variable.
## Prerequisites
To run a Container Scanning job, you need:
- a GitLab Runner with
[docker-in-docker executor](https://docs.gitlab.com/runner/executors/docker.html#use-docker-in-docker-with-privileged-mode).
- to [build and push](../../ci/docker/using_docker_build.md#container-registry-examples) your Docker image
using the [Container Registry](https://docs.gitlab.com/ee/user/project/container_registry.html) running within your GitLab installation.
## Configuring with templates
Since GitLab 11.9, a CI/CD template with the default Container Scanning job definition is provided as a part of your GitLab installation.
This section describes how to use it and customize its execution.
### Using job definition template
CAUTION: **Caution:**
The CI/CD template for job definition is supported on GitLab 11.9 and later versions.
For earlier versions, use the [manual job definition](#manual-job-definition).
Once you set up the Runner, add a new job to `.gitlab-ci.yml` using [the CI/CD template](../../ci/yaml/README.md#includetemplate) for Container Scanning:
```yaml
include:
template: Container-Scanning.gitlab-ci.yml
```
If you want to whitelist some specific vulnerabilities, you can do so by defining
them in a [YAML file](https://github.com/arminc/clair-scanner/blob/master/README.md#example-whitelist-yaml-file),
in our case its named `clair-whitelist.yml`.
### Scanning results
The above example will create a `container_scanning` job in your CI/CD pipeline, pull
the image from the [Container Registry](../../user/project/container_registry.md)
(whose name is defined from the two `CI_APPLICATION_` variables) and scan it
for possible vulnerabilities. The report will be saved as a
[Container Scanning report artifact](../yaml/README.md#artifactsreportscontainer_scanning-ultimate)
that you can later download and analyze.
Due to implementation limitations we always take the latest Container Scanning artifact available.
TIP: **Tip:**
For [GitLab Ultimate][ee] users, this information will
be automatically extracted and shown right in the merge request widget.
[Learn more on Container Scanning in merge requests](../../user/project/merge_requests/container_scanning.html).
## Manual job definition
CAUTION: **Caution:**
The job definition shown below is supported on GitLab 11.5 and later versions _(although it's preferred to use
[the job definition template](#using-job-definition-template) since 11.9)_.
It also requires the GitLab Runner 11.5 or later.
For earlier versions, use the [previous job definitions](#previous-job-definitions).
If you are using GitLab prior to 11.9, you can define it manually using the following snippet:
```yaml
container_scanning:
image: docker:stable
variables:
DOCKER_DRIVER: overlay2
## Define two new variables based on GitLab's CI/CD predefined variables
## https://docs.gitlab.com/ee/ci/variables/#predefined-environment-variables
CI_APPLICATION_REPOSITORY: $CI_REGISTRY_IMAGE/$CI_COMMIT_REF_SLUG
CI_APPLICATION_TAG: $CI_COMMIT_SHA
allow_failure: true
services:
- docker:stable-dind
script:
- docker run -d --name db arminc/clair-db:latest
- docker run -p 6060:6060 --link db:postgres -d --name clair --restart on-failure arminc/clair-local-scan:v2.0.6
- apk add -U wget ca-certificates
- docker pull ${CI_APPLICATION_REPOSITORY}:${CI_APPLICATION_TAG}
- wget https://github.com/arminc/clair-scanner/releases/download/v8/clair-scanner_linux_amd64
- mv clair-scanner_linux_amd64 clair-scanner
- chmod +x clair-scanner
- touch clair-whitelist.yml
- while( ! wget -q -O /dev/null http://docker:6060/v1/namespaces ) ; do sleep 1 ; done
- retries=0
- echo "Waiting for clair daemon to start"
- while( ! wget -T 10 -q -O /dev/null http://docker:6060/v1/namespaces ) ; do sleep 1 ; echo -n "." ; if [ $retries -eq 10 ] ; then echo " Timeout, aborting." ; exit 1 ; fi ; retries=$(($retries+1)) ; done
- ./clair-scanner -c http://docker:6060 --ip $(hostname -i) -r gl-container-scanning-report.json -l clair.log -w clair-whitelist.yml ${CI_APPLICATION_REPOSITORY}:${CI_APPLICATION_TAG} || true
artifacts:
reports:
container_scanning: gl-container-scanning-report.json
```
## Previous job definitions
CAUTION: **Caution:**
Before GitLab 11.5, Container Scanning job and artifact had to be named specifically
to automatically extract report data and show it in the merge request widget.
While these old job definitions are still maintained they have been deprecated
and may be removed in next major release, GitLab 12.0.
You are advised to update your current `.gitlab-ci.yml` configuration to reflect that change.
For GitLab 11.4 and earlier, the job should look like:
```yaml
container_scanning:
image: docker:stable
variables:
DOCKER_DRIVER: overlay2
## Define two new variables based on GitLab's CI/CD predefined variables
## https://docs.gitlab.com/ee/ci/variables/#predefined-environment-variables
CI_APPLICATION_REPOSITORY: $CI_REGISTRY_IMAGE/$CI_COMMIT_REF_SLUG
CI_APPLICATION_TAG: $CI_COMMIT_SHA
allow_failure: true
services:
- docker:stable-dind
script:
- docker run -d --name db arminc/clair-db:latest
- docker run -p 6060:6060 --link db:postgres -d --name clair --restart on-failure arminc/clair-local-scan:v2.0.6
- apk add -U wget ca-certificates
- docker pull ${CI_APPLICATION_REPOSITORY}:${CI_APPLICATION_TAG}
- wget https://github.com/arminc/clair-scanner/releases/download/v8/clair-scanner_linux_amd64
- mv clair-scanner_linux_amd64 clair-scanner
- chmod +x clair-scanner
- touch clair-whitelist.yml
- while( ! wget -q -O /dev/null http://docker:6060/v1/namespaces ) ; do sleep 1 ; done
- retries=0
- echo "Waiting for clair daemon to start"
- while( ! wget -T 10 -q -O /dev/null http://docker:6060/v1/namespaces ) ; do sleep 1 ; echo -n "." ; if [ $retries -eq 10 ] ; then echo " Timeout, aborting." ; exit 1 ; fi ; retries=$(($retries+1)) ; done
- ./clair-scanner -c http://docker:6060 --ip $(hostname -i) -r gl-container-scanning-report.json -l clair.log -w clair-whitelist.yml ${CI_APPLICATION_REPOSITORY}:${CI_APPLICATION_TAG} || true
artifacts:
paths: [gl-container-scanning-report.json]
```
Alternatively, the job name could be `sast:container`
and the artifact name could be `gl-sast-container-report.json`.
These names have been deprecated with GitLab 11.0
and may be removed in next major release, GitLab 12.0.
[ee]: https://about.gitlab.com/pricing/
This document was moved to [another location](../../user/application_security/container_scanning/index.md).
doc/ci/examples/dast.md
View file @ 3d1be386
# Dynamic Application Security Testing with GitLab CI/CD
---
redirect_to: '../../user/application_security/dast/index.md'
---
[Dynamic Application Security Testing (DAST)](https://en.wikipedia.org/wiki/Dynamic_Application_Security_Testing)
is using the popular open source tool [OWASP ZAProxy](https://github.com/zaproxy/zaproxy)
to perform an analysis on your running web application.
Since it is based on [ZAP Baseline](https://github.com/zaproxy/zaproxy/wiki/ZAP-Baseline-Scan)
DAST will perform passive scanning only;
it will not actively attack your application.
It can be very useful combined with [Review Apps](../review_apps/index.md).
These examples show how to run DAST on your running web application by using GitLab CI/CD.
## Prerequisites
To run a DAST job, you need GitLab Runner with
[docker-in-docker executor](https://docs.gitlab.com/runner/executors/docker.html#use-docker-in-docker-with-privileged-mode).
## Configuring with templates
Since GitLab 11.9, a CI/CD template with the default DAST job definition is provided as a part of your GitLab installation.
This section describes how to use it and customize its execution.
### Using job definition template
CAUTION: **Caution:**
The CI/CD template for job definition is supported on GitLab 11.9 and later versions.
For earlier versions, use the [manual job definition](#manual-job-definition).
Once you set up the Runner, add a new job to `.gitlab-ci.yml` using [the CI/CD template](../../ci/yaml/README.md#includetemplate) for DAST:
```yaml
include:
template: DAST.gitlab-ci.yml
variables:
DAST_WEBSITE: https://example.com
```
The above example will create a `dast` job in your CI/CD pipeline which will run
the tests on the specified URL and scan it for possible vulnerabilities.
There are two ways to define the URL to be scanned by DAST:
- The `DAST_WEBSITE` [variable](../../ci/yaml/README.md#variables).
- In an `environment_url.txt` file at the root of your project.
It's also possible to authenticate the user before performing DAST checks:
```yaml
include:
template: DAST.gitlab-ci.yml
variables:
DAST_AUTH_URL: https://example.com/sign-in
DAST_USERNAME: john.doe@example.com
DAST_PASSWORD: john-doe-password
DAST_USERNAME_FIELD: session[user] # the name of username field at the sign-in HTML form
DAST_PASSWORD_FIELD: session[password] # the name of password field at the sign-in HTML form
```
### Scanning results
The report will be saved as a
[DAST report artifact](../yaml/README.md#artifactsreportsdast-ultimate)
that you can later download and analyze.
Due to implementation limitations we always take the latest DAST artifact available.
TIP: **Tip:**
For [GitLab Ultimate][ee] users, this information will
be automatically extracted and shown right in the merge request widget.
[Learn more on DAST in merge requests](../../user/project/merge_requests/dast.md).
### Customizing the template
You can customize DAST job execution in various ways of different granularity.
#### Scanning tool settings
DAST tool settings can be changed through environment variables. These variables are documented in the:
- Job definition [template](#using-job-definition-template).
- DAST [README](https://gitlab.com/gitlab-org/security-products/dast#settings).
The customization itself is performed by using the [`variables`](https://docs.gitlab.com/ee/ci/yaml/#variables)
parameter in the project's pipeline configuration file (`.gitlab-ci.yml`):
```yaml
include:
template: DAST.gitlab-ci.yml
variables:
DAST_TARGET_AVAILABILITY_TIMEOUT: 120
```
Because template is evaluated [before](../yaml/README.md#include) the pipeline configuration,
the last mention of the variable will take precedence.
#### Overriding job definition
If you want to override the job definition (for example, change properties like `variables` or `dependencies`), you need to declare
its definition after the template inclusion and specify any additional keys under it. For example:
```yaml
include:
template: DAST.gitlab-ci.yml
dast:
stage: dast # IMPORTANT: don't forget to add this
variables:
CI_DEBUG_TRACE: "true"
```
CAUTION: **Caution:**
As DAST job belongs to a separate `"dast"` stage that runs after all [default stages](../yaml/README.md#stages),
don't forget to add `stage: dast` entry when you override the template job definition.
## Manual job definition
CAUTION: **Caution:**
The job definition shown below is supported on GitLab 11.5 and later versions _(although it's preferred to use
[the job definition template](#using-job-definition-template) since 11.9)_.
It also requires the GitLab Runner 11.5 or later.
For earlier versions, use the [previous job definitions](#previous-job-definitions).
If you are using GitLab prior to 11.9, you can define it manually using the following snippet:
```yaml
dast:
image: registry.gitlab.com/gitlab-org/security-products/zaproxy
variables:
website: "https://example.com"
allow_failure: true
script:
- mkdir /zap/wrk/
- /zap/zap-baseline.py -J gl-dast-report.json -t $website || true
- cp /zap/wrk/gl-dast-report.json .
artifacts:
reports:
dast: gl-dast-report.json
```
where the `website` variable is supposed to hold the URL to run the tests against.
For an authenticated scan, use the following definition:
```yaml
dast:
image: registry.gitlab.com/gitlab-org/security-products/zaproxy
variables:
website: "https://example.com"
login_url: "https://example.com/sign-in"
username: "john.doe@example.com"
password: "john-doe-password"
allow_failure: true
script:
- mkdir /zap/wrk/
- /zap/zap-baseline.py -J gl-dast-report.json -t $website
--auth-url $login_url
--auth-username $username
--auth-password $password || true
- cp /zap/wrk/gl-dast-report.json .
artifacts:
reports:
dast: gl-dast-report.json
```
See [zaproxy documentation](https://gitlab.com/gitlab-org/security-products/zaproxy)
to learn more about authentication settings.
## Previous job definitions
CAUTION: **Caution:**
Before GitLab 11.5, DAST job and artifact had to be named specifically
to automatically extract report data and show it in the merge request widget.
While these old job definitions are still maintained they have been deprecated
and may be removed in next major release, GitLab 12.0.
You are advised to update your current `.gitlab-ci.yml` configuration to reflect that change.
For GitLab 11.4 and earlier, the job should look like:
```yaml
dast:
image: registry.gitlab.com/gitlab-org/security-products/zaproxy
variables:
website: "https://example.com"
allow_failure: true
script:
- mkdir /zap/wrk/
- /zap/zap-baseline.py -J gl-dast-report.json -t $website || true
- cp /zap/wrk/gl-dast-report.json .
artifacts:
paths: [gl-dast-report.json]
```
[ee]: https://about.gitlab.com/pricing/
This document was moved to [another location](../../user/application_security/dast/index.md).
doc/ci/examples/dependency_scanning.md
View file @ 3d1be386
# Dependency Scanning with GitLab CI/CD **[ULTIMATE]**
---
redirect_to: '../../user/application_security/dependency_scanning/index.md'
---
These examples show how to run Dependency Scanning on your project's dependencies by using GitLab CI/CD.
## Prerequisites
To run a Dependency Scanning job, you need GitLab Runner with
[docker-in-docker executor](https://docs.gitlab.com/runner/executors/docker.html#use-docker-in-docker-with-privileged-mode).
## Configuring with templates
Since GitLab 11.9, a CI/CD template with the default Dependency Scanning job definition is provided as a part of your GitLab installation.
This section describes how to use it and customize its execution.
### Using job definition template
CAUTION: **Caution:**
The CI/CD template for job definition is supported on GitLab 11.9 and later versions.
For earlier versions, use the [manual job definition](#manual-job-definition).
Once you set up the Runner, add a new job to `.gitlab-ci.yml` using [the CI/CD template](../../ci/yaml/README.md#includetemplate) for Dependency Scanning:
```yaml
include:
template: Dependency-Scanning.gitlab-ci.yml
```
### Scanning results
The above example will create a `dependency_scanning` job in your CI/CD pipeline
and scan your dependencies for possible vulnerabilities. The report will be saved as a
[Dependency Scanning report artifact](../../ci/yaml/README.md#artifactsreportsdependency_scanning-ultimate)
that you can later download and analyze.
Due to implementation limitations we always take the latest Dependency Scanning artifact available.
The results are sorted by the priority of the vulnerability:
1. High
1. Medium
1. Low
1. Unknown
1. Everything else
Behind the scenes, the [GitLab Dependency Scanning Docker image](https://gitlab.com/gitlab-org/security-products/dependency-scanning)
is used to detect the languages/package managers and in turn runs the matching scan tools.
Some security scanners require to send a list of project dependencies to GitLab
central servers to check for vulnerabilities. To learn more about this or to
disable it, check the [GitLab Dependency Scanning documentation](https://gitlab.com/gitlab-org/security-products/dependency-scanning#remote-checks)
and the [customization guide](#customizing-the-template).
TIP: **Tip:**
For [GitLab Ultimate][ee] users, this information will
be automatically extracted and shown right in the merge request widget.
[Learn more on Dependency Scanning in merge requests](../../user/project/merge_requests/dependency_scanning.md).
### Customizing the template
You can customize Dependency Scanning job execution in various ways of different granularity.
#### Scanning tool settings
Dependency Scanning tool settings can be changed through environment variables. These variables are documented in the:
- Job definition [template](#using-job-definition-template).
- Dependency Scanning [README](https://gitlab.com/gitlab-org/security-products/dependency-scanning#settings).
The customization itself is performed by using the [`variables`](https://docs.gitlab.com/ee/ci/yaml/#variables)
parameter in the project's pipeline configuration file (`.gitlab-ci.yml`):
```yaml
include:
template: Dependency-Scanning.gitlab-ci.yml
variables:
DEP_SCAN_DISABLE_REMOTE_CHECKS: true
```
Because template is evaluated [before](../yaml/README.md#include) the pipeline configuration,
the last mention of the variable will take precedence.
#### Overriding job definition
If you want to override the job definition (for example, change properties like `variables` or `dependencies`), you need to declare
its definition after the template inclusion and specify any additional keys under it. For example:
```yaml
include:
template: Dependency-Scanning.gitlab-ci.yml
dependency_scanning:
variables:
CI_DEBUG_TRACE: "true"
```
## Manual job definition
CAUTION: **Caution:**
The job definition shown below is supported on GitLab 11.5 and later versions _(although it's preferred to use
[the job definition template](#using-job-definition-template) since 11.9)_.
It also requires the GitLab Runner 11.5 or later.
For earlier versions, use the [previous job definitions](#previous-job-definitions).
If you are using GitLab prior to 11.9, you can define it manually using the following snippet:
```yaml
dependency_scanning:
image: docker:stable
variables:
DOCKER_DRIVER: overlay2
allow_failure: true
services:
- docker:stable-dind
script:
- export DS_VERSION=${SP_VERSION:-$(echo "$CI_SERVER_VERSION" | sed 's/^\([0-9]*\)\.\([0-9]*\).*/\1-\2-stable/')}
- |
docker run \
--env DS_ANALYZER_IMAGES \
--env DS_ANALYZER_IMAGE_PREFIX \
--env DS_ANALYZER_IMAGE_TAG \
--env DS_DEFAULT_ANALYZERS \
--env DEP_SCAN_DISABLE_REMOTE_CHECKS \
--env DS_DOCKER_CLIENT_NEGOTIATION_TIMEOUT \
--env DS_PULL_ANALYZER_IMAGE_TIMEOUT \
--env DS_RUN_ANALYZER_TIMEOUT \
--volume "$PWD:/code" \
--volume /var/run/docker.sock:/var/run/docker.sock \
"registry.gitlab.com/gitlab-org/security-products/dependency-scanning:$DS_VERSION" /code
dependencies: []
artifacts:
reports:
dependency_scanning: gl-dependency-scanning-report.json
```
You can supply many other [settings variables](https://gitlab.com/gitlab-org/security-products/dependency-scanning#settings)
via `docker run --env` to customize your job execution.
## Previous job definitions
CAUTION: **Caution:**
Before GitLab 11.5, Dependency Scanning job and artifact had to be named specifically
to automatically extract report data and show it in the merge request widget.
While these old job definitions are still maintained they have been deprecated
and may be removed in next major release, GitLab 12.0.
You are advised to update your current `.gitlab-ci.yml` configuration to reflect that change.
For GitLab 11.4 and earlier, the job should look like:
```yaml
dependency_scanning:
image: docker:stable
variables:
DOCKER_DRIVER: overlay2
allow_failure: true
services:
- docker:stable-dind
script:
- export DS_VERSION=${SP_VERSION:-$(echo "$CI_SERVER_VERSION" | sed 's/^\([0-9]*\)\.\([0-9]*\).*/\1-\2-stable/')}
- |
docker run \
--env DS_ANALYZER_IMAGES \
--env DS_ANALYZER_IMAGE_PREFIX \
--env DS_ANALYZER_IMAGE_TAG \
--env DS_DEFAULT_ANALYZERS \
--env DEP_SCAN_DISABLE_REMOTE_CHECKS \
--env DS_DOCKER_CLIENT_NEGOTIATION_TIMEOUT \
--env DS_PULL_ANALYZER_IMAGE_TIMEOUT \
--env DS_RUN_ANALYZER_TIMEOUT \
--volume "$PWD:/code" \
--volume /var/run/docker.sock:/var/run/docker.sock \
"registry.gitlab.com/gitlab-org/security-products/dependency-scanning:$DS_VERSION" /code
artifacts:
paths: [gl-dependency-scanning-report.json]
```
## Supported languages and package managers
See [the full list of supported languages and package managers](../../user/project/merge_requests/dependency_scanning.md#supported-languages-and-dependency-managers).
[ee]: https://about.gitlab.com/pricing/
This document was moved to [another location](../../user/application_security/dependency_scanning/index.md).
doc/ci/examples/license_management.md
View file @ 3d1be386
# Dependencies license management with GitLab CI/CD **[ULTIMATE]**
---
redirect_to: '../../user/application_security/license_management/index.md'
---
These examples show how to run License Management scanning on your project's dependencies by using GitLab CI/CD.
## Prerequisites
To run a License Management scanning job, you need GitLab Runner with
[docker executor](https://docs.gitlab.com/runner/executors/docker.html).
## Configuring with templates
Since GitLab 11.9, a CI/CD template with the default License Management scanning job definition is provided as a part of your GitLab installation.
This section describes how to use it and customize its execution.
### Using job definition template
CAUTION: **Caution:**
The CI/CD template for job definition is supported on GitLab 11.9 and later versions.
For earlier versions, use the [manual job definition](#manual-job-definition).
Once you set up the Runner, add a new job to `.gitlab-ci.yml` using [the CI/CD template](../../ci/yaml/README.md#includetemplate) for License Management:
```yaml
include:
template: License-Management.gitlab-ci.yml
```
### Scanning results
The above example will create a `license_management` job in your CI/CD pipeline
and scan your dependencies to find their licenses. The report will be saved as a
[License Management report artifact](../../ci/yaml/README.md#artifactsreportslicense_management-ultimate)
that you can later download and analyze.
Due to implementation limitations we always take the latest License Management artifact available.
TIP: **Tip:**
For [GitLab Ultimate][ee] users, this information will
be automatically extracted and shown right in the merge request widget.
[Learn more on License Management in merge requests](../../user/project/merge_requests/license_management.md).
### Customizing the template
#### Install custom project dependencies
> Introduced in GitLab Ultimate 11.4.
The `license_management` image already embeds many auto-detection scripts, languages,
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 `SETUP_CMD` environment variable can be passed to the container,
with the required commands to run before license detection.
If present, this variable will override the setup step necessary to install all the packages
of your application (ex: for a project with a `Gemfile`, the setup step will be `bundle install`).
Example:
```yaml
include:
template: License-Management.gitlab-ci.yml
variables:
LICENSE_MANAGEMENT_SETUP_CMD: ./my-custom-install-script.sh
```
In this example, `my-custom-install-script.sh` is a shell script at the root of the project.
#### Overriding job definition
If you want to override the job definition (for example, change properties like `variables` or `dependencies`), you need to declare
its definition after the template inclusion and specify any additional keys under it. For example:
```yaml
include:
template: License-Management.gitlab-ci.yml
license_management:
stage: my-custom-stage
```
## Manual job definition
CAUTION: **Caution:**
The job definition shown below is supported on GitLab 11.5 and later versions _(although it's preferred to use
[the job definition template](#using-job-definition-template) since 11.9)_.
It also requires the GitLab Runner 11.5 or later.
For earlier versions, use the [previous job definitions](#previous-job-definitions).
If you are using GitLab prior to 11.9, you can define it manually using the following snippet:
```yaml
license_management:
image:
name: "registry.gitlab.com/gitlab-org/security-products/license-management:$CI_SERVER_VERSION_MAJOR-$CI_SERVER_VERSION_MINOR-stable"
entrypoint: [""]
stage: test
allow_failure: true
script:
- /run.sh analyze .
artifacts:
reports:
license_management: gl-license-management-report.json
```
Install custom project dependencies via `SETUP_CMD` variable:
```yaml
license_management:
image:
name: "registry.gitlab.com/gitlab-org/security-products/license-management:$CI_SERVER_VERSION_MAJOR-$CI_SERVER_VERSION_MINOR-stable"
entrypoint: [""]
stage: test
variables:
SETUP_CMD: ./my-custom-install-script.sh
allow_failure: true
script:
- /run.sh analyze .
artifacts:
reports:
license_management: gl-license-management-report.json
```
## Maven projects configuration
The License Management tool provides a `MAVEN_CLI_OPTS` environment variable which can hold
the command line arguments to pass to the `mvn install` command which is executed under the hood.
Feel free to use it for the customization of Maven execution, e.g.:
```yaml
include:
template: License-Management.gitlab-ci.yml
license_management:
variables:
MAVEN_CLI_OPTS: --debug
```
CAUTION: **Caution:**
`mvn install` runs through all of the [build life cycle](http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html)
stages prior to `"install"`, including `"test"`. Running unit tests is not directly necessary
for the license scanning purposes and consumes time, so it's skipped by having the default value of `MAVEN_CLI_OPTS`
as `-DskipTests`. If you want to supply custom `MAVEN_CLI_OPTS`, don't forget to add `-DskipTests` to your
options.
TIP: **Tip:**
If you still need to run tests during `mvn install`, supply `MAVEN_CLI_OPTS` with value `-DskipTests=false`.
## Previous job definitions
CAUTION: **Caution:**
Before GitLab 11.5, License Management job and artifact had to be named specifically
to automatically extract report data and show it in the merge request widget.
While these old job definitions are still maintained they have been deprecated
and may be removed in next major release, GitLab 12.0.
You are advised to update your current `.gitlab-ci.yml` configuration to reflect that change.
For GitLab 11.4 and earlier, the job should look like:
```yaml
license_management:
image:
name: "registry.gitlab.com/gitlab-org/security-products/license-management:$CI_SERVER_VERSION_MAJOR-$CI_SERVER_VERSION_MINOR-stable"
entrypoint: [""]
stage: test
allow_failure: true
script:
- /run.sh analyze .
artifacts:
paths: [gl-license-management-report.json]
```
[ee]: https://about.gitlab.com/pricing/
This document was moved to [another location](../../user/application_security/license_management/index.md).
doc/ci/examples/sast.md
View file @ 3d1be386
# Static Application Security Testing with GitLab CI/CD **[ULTIMATE]**
---
redirect_to: '../../user/application_security/sast/index.md'
---
These examples show how to run [Static Application Security Testing (SAST)](https://en.wikipedia.org/wiki/Static_program_analysis)
on your project's source code by using GitLab CI/CD.
## Prerequisites
To run a SAST job, you need GitLab Runner with
[docker-in-docker executor](https://docs.gitlab.com/runner/executors/docker.html#use-docker-in-docker-with-privileged-mode).
## Configuring with templates
Since GitLab 11.9, a CI/CD template with the default SAST job definition is provided as a part of your GitLab installation.
This section describes how to use it and customize its execution.
### Using job definition template
CAUTION: **Caution:**
The CI/CD template for job definition is supported on GitLab 11.9 and later versions.
For earlier versions, use the [manual job definition](#manual-job-definition).
Once you set up the Runner, add a new job to `.gitlab-ci.yml` using [the CI/CD template](../../ci/yaml/README.md#includetemplate) for SAST:
```yaml
include:
template: SAST.gitlab-ci.yml
```
### Scanning results
The above example will create a `sast` job in your CI/CD pipeline
and scan your project's source code for possible vulnerabilities. The report will be saved as a
[SAST report artifact](../../ci/yaml/README.md#artifactsreportssast-ultimate)
that you can later download and analyze.
Due to implementation limitations we always take the latest SAST artifact available.
The results are sorted by the priority of the vulnerability:
1. Critical
1. High
1. Medium
1. Low
1. Unknown
1. Everything else
Behind the scenes, the [GitLab SAST Docker image](https://gitlab.com/gitlab-org/security-products/sast)
is used to detect the languages/frameworks and in turn runs the matching scan tools.
TIP: **Tip:**
For [GitLab Ultimate][ee] users, this information will
be automatically extracted and shown right in the merge request widget.
[Learn more on SAST in merge requests](../../user/project/merge_requests/sast.md).
### Customizing the template
You can customize SAST job execution in various ways of different granularity.
#### Scanning tool settings
SAST tool settings can be changed through environment variables. These variables are documented in the:
- Job definition [template](#using-job-definition-template).
- SAST [README](https://gitlab.com/gitlab-org/security-products/sast#settings).
The customization itself is performed by using the [`variables`](https://docs.gitlab.com/ee/ci/yaml/#variables)
parameter in the project's pipeline configuration file (`.gitlab-ci.yml`):
```yaml
include:
template: SAST.gitlab-ci.yml
variables:
SAST_GOSEC_LEVEL: 2
```
Because template is evaluated [before](../yaml/README.md#include) the pipeline configuration,
the last mention of the variable will take precedence.
#### Overriding job definition
If you want to override the job definition (for example, change properties like `variables` or `dependencies`), you need to declare
its definition after the template inclusion and specify any additional keys under it. For example:
```yaml
include:
template: SAST.gitlab-ci.yml
sast:
variables:
CI_DEBUG_TRACE: "true"
```
## Manual job definition
CAUTION: **Caution:**
The job definition shown below is supported on GitLab 11.5 and later versions _(although it's preferred to use
[the job definition template](#using-job-definition-template) since 11.9)_.
It also requires the GitLab Runner 11.5 or later.
For earlier versions, use the [previous job definitions](#previous-job-definitions).
If you are using GitLab prior to 11.9, you can define it manually using the following snippet:
```yaml
sast:
stage: test
image: docker:stable
variables:
DOCKER_DRIVER: overlay2
allow_failure: true
services:
- docker:stable-dind
script:
- export SAST_VERSION=${SP_VERSION:-$(echo "$CI_SERVER_VERSION" | sed 's/^\([0-9]*\)\.\([0-9]*\).*/\1-\2-stable/')}
- |
docker run \
--env SAST_ANALYZER_IMAGES \
--env SAST_ANALYZER_IMAGE_PREFIX \
--env SAST_ANALYZER_IMAGE_TAG \
--env SAST_DEFAULT_ANALYZERS \
--env SAST_BRAKEMAN_LEVEL \
--env SAST_GOSEC_LEVEL \
--env SAST_FLAWFINDER_LEVEL \
--env SAST_DOCKER_CLIENT_NEGOTIATION_TIMEOUT \
--env SAST_PULL_ANALYZER_IMAGE_TIMEOUT \
--env SAST_RUN_ANALYZER_TIMEOUT \
--volume "$PWD:/code" \
--volume /var/run/docker.sock:/var/run/docker.sock \
"registry.gitlab.com/gitlab-org/security-products/sast:$SAST_VERSION" /app/bin/run /code
dependencies: []
artifacts:
reports:
sast: gl-sast-report.json
```
You can supply many other [settings variables](https://gitlab.com/gitlab-org/security-products/sast#settings)
via `docker run --env` to customize your job execution.
## Previous job definitions
CAUTION: **Caution:**
Before GitLab 11.5, SAST job and artifact had to be named specifically
to automatically extract report data and show it in the merge request widget.
While these old job definitions are still maintained they have been deprecated
and may be removed in next major release, GitLab 12.0.
You are advised to update your current `.gitlab-ci.yml` configuration to reflect that change.
For GitLab 11.4 and earlier, the job should look like:
```yaml
sast:
image: docker:stable
variables:
DOCKER_DRIVER: overlay2
allow_failure: true
services:
- docker:stable-dind
script:
- export SAST_VERSION=${SP_VERSION:-$(echo "$CI_SERVER_VERSION" | sed 's/^\([0-9]*\)\.\([0-9]*\).*/\1-\2-stable/')}
- docker run
--env SAST_CONFIDENCE_LEVEL="${SAST_CONFIDENCE_LEVEL:-3}"
--volume "$PWD:/code"
--volume /var/run/docker.sock:/var/run/docker.sock
"registry.gitlab.com/gitlab-org/security-products/sast:$SAST_VERSION" /app/bin/run /code
artifacts:
paths: [gl-sast-report.json]
```
[ee]: https://about.gitlab.com/pricing/
This document was moved to [another location](../../user/application_security/sast/index.md).
doc/ci/examples/sast_docker.md
View file @ 3d1be386
---
redirect_to: 'container_scanning.md'
redirect_to: '../../user/application_security/container_scanning/index.md'
---
This document was moved to [another location](container_scanning.md).
This document was moved to [another location](../../user/application_security/container_scanning/index.md).
doc/ci/yaml/README.md
View file @ 3d1be386
......@@ -1457,7 +1457,7 @@ dashboards.
> Introduced in GitLab 11.5. Requires GitLab Runner 11.5 and above.
The `dependency_scanning` report collects [Dependency Scanning vulnerabilities](https://docs.gitlab.com/ee/user/project/merge_requests/dependency_scanning.html)
The `dependency_scanning` report collects [Dependency Scanning vulnerabilities](../../user/application_security/dependency_scanning/index.md)
as artifacts.
The collected Dependency Scanning report will be uploaded to GitLab as an artifact and will
......@@ -1468,7 +1468,7 @@ dashboards.
> Introduced in GitLab 11.5. Requires GitLab Runner 11.5 and above.
The `container_scanning` report collects [Container Scanning vulnerabilities](https://docs.gitlab.com/ee/user/project/merge_requests/container_scanning.html)
The `container_scanning` report collects [Container Scanning vulnerabilities](../../user/application_security/container_scanning/index.md)
as artifacts.
The collected Container Scanning report will be uploaded to GitLab as an artifact and will
......@@ -1479,7 +1479,7 @@ dashboards.
> Introduced in GitLab 11.5. Requires GitLab Runner 11.5 and above.
The `dast` report collects [DAST vulnerabilities](https://docs.gitlab.com/ee/user/project/merge_requests/dast.html)
The `dast` report collects [DAST vulnerabilities](../../user/application_security/dast/index.md)
as artifacts.
The collected DAST report will be uploaded to GitLab as an artifact and will
......
doc/development/go_guide/index.md
View file @ 3d1be386
......@@ -40,7 +40,7 @@ of possible security breaches in our code:
- SQL injections
Remember to run
[SAST](../../user/project/merge_requests/sast.md)
[SAST](../../user/application_security/sast/index.md)
**[ULTIMATE]** on your project (or at least the [gosec
analyzer](https://gitlab.com/gitlab-org/security-products/analyzers/gosec)),
and to follow our [Security
......@@ -94,9 +94,9 @@ become available, you will be able to share job templates like this
Dependencies should be kept to the minimum. The introduction of a new
dependency should be argued in the merge request, as per our [Approval
Guidelines](../code_review.md#approval-guidelines). Both [License
Management](../../user/project/merge_requests/license_management.md)
Management](../../user/application_security/license_management/index.md)
**[ULTIMATE]** and [Dependency
Scanning](../../user/project/merge_requests/dependency_scanning.md)
Scanning](../../user/application_security/dependency_scanning/index.md)
**[ULTIMATE]** should be activated on all projects to ensure new dependencies
security status and license compatibility.
......
doc/topics/autodevops/index.md
View file @ 3d1be386
......@@ -377,8 +377,8 @@ analysis on the current code and checks for potential security issues. Once the
report is created, it's uploaded as an artifact which you can later download and
check out.
Any security warnings are also
[shown in the merge request widget](../../user/project/merge_requests/sast.md).
Any security warnings are also shown in the merge request widget. Read more how
[SAST works](../../user/application_security/sast/index.md).
NOTE: **Note:**
The Auto SAST stage will be skipped on licenses other than Ultimate.
......@@ -396,8 +396,8 @@ to run analysis on the project dependencies and checks for potential security is
report is created, it's uploaded as an artifact which you can later download and
check out.
Any security warnings are also
[shown in the merge request widget](../../user/project/merge_requests/dependency_scanning.md).
Any security warnings are also shown in the merge request widget. Read more about
[Dependency Scanning](../../user/application_security/dependency_scanning/index.md).
NOTE: **Note:**
The Auto Dependency Scanning stage will be skipped on licenses other than Ultimate.
......@@ -415,8 +415,8 @@ to search the project dependencies for their license. Once the
report is created, it's uploaded as an artifact which you can later download and
check out.
Any licenses are also
[shown in the merge request widget](../../user/project/merge_requests/license_management.md).
Any licenses are also shown in the merge request widget. Read more how
[License Management works](../../user/application_security/license_management/index.md).
NOTE: **Note:**
The Auto License Management stage will be skipped on licenses other than Ultimate.
......@@ -431,8 +431,8 @@ Docker image and checks for potential security issues. Once the report is
created, it's uploaded as an artifact which you can later download and
check out.
Any security warnings are also
[shown in the merge request widget](https://docs.gitlab.com/ee//user/project/merge_requests/container_scanning.html).
Any security warnings are also shown in the merge request widget. Read more how
[Container Scanning works](../..//user/application_security/container_scanning/index.md).
NOTE: **Note:**
The Auto Container Scanning stage will be skipped on licenses other than Ultimate.
......@@ -487,8 +487,8 @@ to perform an analysis on the current code and checks for potential security
issues. Once the report is created, it's uploaded as an artifact which you can
later download and check out.
Any security warnings are also
[shown in the merge request widget](https://docs.gitlab.com/ee//user/project/merge_requests/dast.html).
Any security warnings are also shown in the merge request widget. Read how
[DAST works](../../user/application_security/dast/index.md).
NOTE: **Note:**
The Auto DAST stage will be skipped on licenses other than Ultimate.
......
doc/user/application_security/container_scanning/index.md
View file @ 3d1be386
---
is_hidden: true
---
# Container Scanning **[ULTIMATE]**
> [Introduced](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/3672)
......@@ -14,7 +10,7 @@ images (or more precisely the containers) for known vulnerabilities by using
[Clair](https://github.com/coreos/clair) and [clair-scanner](https://github.com/arminc/clair-scanner),
two open source tools for Vulnerability Static Analysis for containers.
You can take advantage of Container Scanning by either [including the CI job](../../../ci/examples/container_scanning.md) in
You can take advantage of Container Scanning by either [including the CI job](#including-the-provided-template) in
your existing `.gitlab-ci.yml` file or by implicitly using
[Auto Container Scanning](../../../topics/autodevops/index.md#auto-container-scanning)
that is provided by [Auto DevOps](../../../topics/autodevops/index.md).
......
doc/user/application_security/dast/index.md
View file @ 3d1be386
---
is_hidden: true
---
# Dynamic Application Security Testing (DAST) **[ULTIMATE]**
> [Introduced](https://gitlab.com/gitlab-org/gitlab-ee/issues/4348)
......
doc/user/application_security/dependency_scanning/index.md
View file @ 3d1be386
......@@ -8,8 +8,8 @@ in [GitLab Ultimate](https://about.gitlab.com/pricing/) 10.7.
If you are using [GitLab CI/CD](../../../ci/README.md), you can analyze your dependencies for known
vulnerabilities using Dependency Scanning.
You can take advantage of Dependency Scanning by either [including the CI job](../../../ci/examples/dependency_scanning.md) in
your existing `.gitlab-ci.yml` file or by implicitly using
You can take advantage of Dependency Scanning by either [including the CI job](#including-the-provided-template)
in your existing `.gitlab-ci.yml` file or by implicitly using
[Auto Dependency Scanning](../../../topics/autodevops/index.md#auto-dependency-scanning-ultimate)
that is provided by [Auto DevOps](../../../topics/autodevops/index.md).
......
doc/user/application_security/index.md
View file @ 3d1be386
---
is_hidden: true
---
# GitLab Secure **[ULTIMATE]**
Check your application for security vulnerabilities that may lead to unauthorized access,
......
doc/user/application_security/license_management/index.md
View file @ 3d1be386
---
is_hidden: true
---
# License Management **[ULTIMATE]**
> [Introduced](https://gitlab.com/gitlab-org/gitlab-ee/issues/5483)
......
doc/user/application_security/sast/index.md
View file @ 3d1be386
---
is_hidden: true
---
# Static Application Security Testing (SAST) **[ULTIMATE]**
> [Introduced](https://gitlab.com/gitlab-org/gitlab-ee/issues/3775)
......
doc/user/application_security/security_dashboard/index.md
View file @ 3d1be386
---
is_hidden: true
---
# GitLab Security Dashboard **[ULTIMATE]**
The Security Dashboard is a good place to get an overview of all the security
......
doc/user/group/security_dashboard/index.md
View file @ 3d1be386
---
description: "The Group Security Dashboard gives an overview of the vulnerabilities of all the projects in a group and its subgroups."
redirect_to: '../../application_security/security_dashboard/index.md'
---
# Group Security Dashboard **[ULTIMATE]**
> [Introduced](https://gitlab.com/gitlab-org/gitlab-ee/issues/6709) in
[GitLab Ultimate](https://about.gitlab.com/pricing) 11.5.
The Group Security Dashboard gives an overview of the vulnerabilities of all the
projects in a group and its subgroups.
## Overview
To use the Group Security Dashboard, you need a group that has at least one
project with [Static Application Security Testing](../../project/merge_requests/sast.md) or [Dependency Scanning](../../project/merge_requests/dependency_scanning.md)
enabled.
The Dashboard is a good place to get an overview of the security vulnerabilities in your projects.
You can also drill down into a vulnerability and get extra information, see which
project it comes from, the file it's in, and various metadata to help you analyze
the risk. You can also action these vulnerabilities by creating an issue for them, or by dismissing them.
Having your vulnerabilities in GitLab allows you to keep track of them and action them, all in the same application.
![dashboard with action buttons and metrics](img/dashboard.png)
## Use cases
You want to measure how secure your projects are without having to look into
each one separately.
## Supported features
The group security dashboard supports [SAST](../../project/merge_requests/sast.md),
[Dependency Scanning](../../project/merge_requests/dependency_scanning.md),
[Container Scanning](../../project/merge_requests/container_scanning.md),
and [DAST](../../project/merge_requests/dast.md).
## Requirements
To use the group security dashboard:
1. At least one project inside a group must be configured with
[Static Application Security Testing](../../project/merge_requests/sast.md), or [Dependency Scanning](../../project/merge_requests/dependency_scanning.md),
or [Container Scanning](../../project/merge_requests/container_scanning.md), or [Dynamic Application Security Testing](../../project/merge_requests/dast.md).
2. The configured jobs must use the [new `reports` syntax](../../../ci/yaml/README.md#artifactsreports) (see an [example job](../../../ci/examples/sast.md)).
3. [GitLab Runner](https://docs.gitlab.com/runner/) 11.5 or above must be used to execute the jobs.
## Keeping the dashboard up to date
Vulnerabilities are spotted during CI/CD pipelines, so having up-to-date results
depends on how often security jobs are run.
In order to have the latest results displayed in the dashboard, you can
[schedule a daily pipeline](../../project/pipelines/schedules.md), so reports
are created even if no code change happens.
## Viewing the vulnerabilities
First, navigate to the Security Dashboard found under your group's
**Overview > Security Dashboard**.
Once you're on the dashboard, at the top you should see a series of filters for:
- Severity
- Report type
- Project
Selecting one or more filters will filter the results in this page.
The first section is an overview of all the vulnerabilities, grouped by severity.
Underneath this overview is a timeline chart that shows how many open
vulnerabilities your projects had at various points in time. You can filter among 30, 60, and
90 days, with the default being 90. Hover over the chart to get more details about
the open vulnerabilities at a specific time.
Finally, there is a list of all the vulnerabilities in the group, sorted by severity.
In that list, you can see the severity of the vulnerability, its name, its
confidence (likelihood of the vulnerability to be a positive one), and the project
it's from.
If you hover over a row, there will appear some actions you can take:
- "More info"
- "Create issue"
- "Dismiss vulnerability"
### Getting more information for a vulnerability
Clicking the "More info" button opens a modal with more information about the
selected vulnerability where you can get a better description, as well as the
file it came from, and a possible solution. You get access to the
["Dismiss vulnerability"](#dismissing-a-vulnerability),
["Create merge request"](#create-a-merge-request-from-a-vulnerability), and
["Create issue"](#creating-an-issue-for-a-vulnerability) buttons inside this
modal as well.
![more info modal](img/modal.png)
### Creating an issue for a vulnerability
You can create an issue for a vulnerability by selecting the "Create issue"
button from the action buttons to the right of a vulnerability row.
This will create an issue on the project this vulnerability came from and pre-fill
it with some useful information.
Once the issue is created, you will be redirected to it so you can edit, assign,
or comment on it. Upon returning to the dashboard you'll see that the vulnerability
will now have an associated issue next to the name.
![linked issue](img/issue.png)
You can get the same result if you select the **Create issue** button from inside
the "More info" modal.
### Create a Merge Request from a vulnerability
> [Introduced](https://gitlab.com/gitlab-org/gitlab-ee/issues/9224) in
[GitLab Ultimate](https://about.gitlab.com/pricing) 11.9.
In certain cases, GitLab will allow you to create a merge request that will
automatically remediate the vulnerability.
Clicking on the "Create merge request" button inside the more info modal will create
a merge request onto the default branch, then redirect you to that merge request.
CAUTION: **Warning:** Automatic Patch creation is only available for a subset of
[Dependency Scanning](../../project/merge_requests/dependency_scanning.md). At the moment only Node.JS projects
managed with yarn are supported.
### Dismissing a vulnerability
You can also dismiss vulnerabilities by clicking the "Dismiss vulnerability" button.
This will dismiss the vulnerability and re-render it to reflect its dismissed state.
If you wish to undo this dismissal, you can click the "Undo dismiss" button.
You can get the same behaviour if you dismiss a vulnerability from within the
"More info" modal.
This document was moved to [another location](../../application_security/security_dashboard/index.md).
doc/user/project/merge_requests/container_scanning.md
View file @ 3d1be386
# Container Scanning **[ULTIMATE]**
---
redirect_to: '../../application_security/container_scanning/index.md'
---
> [Introduced](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/3672)
in [GitLab Ultimate](https://about.gitlab.com/pricing/) 10.4.
> [Introduced][ee-3672] in [GitLab Ultimate][ee] 10.4.
## Overview
If you are using [GitLab CI/CD](../../../ci/README.md), you can analyze your Docker images for known
vulnerabilities using [Clair](https://github.com/coreos/clair),
a Vulnerability Static Analysis tool for containers.
You can take advantage of Container Scanning by either [including the CI job](../../../ci/examples/container_scanning.md) in
your existing `.gitlab-ci.yml` file or by implicitly using
[Auto Container Scanning](../../../topics/autodevops/index.md#auto-container-scanning)
that is provided by [Auto DevOps](../../../topics/autodevops/index.md).
Going a step further, GitLab can show the vulnerability list right in the merge
request widget area.
![Container Scanning Widget](img/container_scanning.png)
## Use cases
If you distribute your application with Docker, then there's a great chance
that your image is based on other Docker images that may in turn contain some
known vulnerabilities that could be exploited.
Having an extra job in your pipeline that checks for those vulnerabilities,
and the fact that they are displayed inside a merge request, makes it very easy
to perform audits for your Docker-based apps.
## How it works
First of all, you need to define a job in your `.gitlab-ci.yml` file that generates the
[Container Scanning report artifact](../../../ci/yaml/README.md#artifactsreportscontainer_scanning-ultimate).
For more information on how the Container Scanning job should look like, check the
example on [Container Scanning with GitLab CI/CD](../../../ci/examples/container_scanning.md).
GitLab then checks this report, compares the found vulnerabilities between the source and target
branches, and shows the information right on the merge request.
This document was moved to [another location](../../application_security/container_scanning/index.md).
doc/user/project/merge_requests/dast.md
View file @ 3d1be386
# Dynamic Application Security Testing (DAST) **[ULTIMATE]**
---
redirect_to: '../../application_security/dast/index.md'
---
> [Introduced](https://gitlab.com/gitlab-org/gitlab-ee/issues/4348)
in [GitLab Ultimate](https://about.gitlab.com/pricing/) 10.4.
## Overview
Running [static checks](sast.md) on your code is the first step to detect
vulnerabilities that can put the security of your code at risk. Yet, once
deployed, your application is exposed to a new category of possible attacks,
such as cross-site scripting or broken authentication flaws. This is where
Dynamic Application Security Testing (DAST) comes into place.
If you are using [GitLab CI/CD](../../../ci/README.md), you can analyze your running web application(s)
for known vulnerabilities using Dynamic Application Security Testing (DAST).
You can take advantage of DAST by either [including the CI job](../../../ci/examples/dast.md) in
your existing `.gitlab-ci.yml` file or by implicitly using
[Auto DAST](../../../topics/autodevops/index.md#auto-dast-ultimate)
that is provided by [Auto DevOps](../../../topics/autodevops/index.md).
Going a step further, GitLab can show the vulnerability list right in the merge
request widget area.
## Use cases
It helps you automatically find security vulnerabilities in your running web
applications while you are developing and testing your applications.
## How it works
First of all, you need to define a job in your `.gitlab-ci.yml` file that generates the
[DAST report artifact](../../../ci/yaml/README.md#artifactsreportsdast-ultimate).
For more information on how the DAST job should look like, check the
example on [Dynamic Application Security Testing with GitLab CI/CD](../../../ci/examples/dast.md).
GitLab then checks this report, compares the found vulnerabilities between the source and target
branches, and shows the information right on the merge request.
![DAST Widget](img/dast_all.png)
By clicking on one of the detected linked vulnerabilities, you will be able to
see the details and the URL(s) affected.
![DAST Widget Clicked](img/dast_single.png)
This document was moved to [another location](../../application_security/dast/index.md).
doc/user/project/merge_requests/dependency_scanning.md
View file @ 3d1be386
# Dependency Scanning **[ULTIMATE]**
---
redirect_to: '../../application_security/dependency_scanning/index.md'
---
> [Introduced](https://gitlab.com/gitlab-org/gitlab-ee/issues/5105)
in [GitLab Ultimate](https://about.gitlab.com/pricing/) 10.7.
## Overview
If you are using [GitLab CI/CD](../../../ci/README.md), you can analyze your dependencies for known
vulnerabilities using Dependency Scanning.
You can take advantage of Dependency Scanning by either [including the CI job](../../../ci/examples/dependency_scanning.md) in
your existing `.gitlab-ci.yml` file or by implicitly using
[Auto Dependency Scanning](../../../topics/autodevops/index.md#auto-dependency-scanning-ultimate)
that is provided by [Auto DevOps](../../../topics/autodevops/index.md).
Going a step further, GitLab can show the vulnerability list right in the merge
request widget area.
## Use cases
It helps you automatically find security vulnerabilities in your dependencies
while you are developing and testing your applications. E.g. your application
is using an external (open source) library which is known to be vulnerable.
## Supported languages and dependency managers
The following languages and dependency managers are supported.
| Language (package managers) | Scan tool |
|-----------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------|
| JavaScript ([npm](https://www.npmjs.com/), [yarn](https://yarnpkg.com/en/)) | [gemnasium](https://gitlab.com/gitlab-org/security-products/gemnasium/general), [Retire.js](https://retirejs.github.io/retire.js) |
| Python ([pip](https://pip.pypa.io/en/stable/)) (only `requirements.txt` supported) | [gemnasium](https://gitlab.com/gitlab-org/security-products/gemnasium/general) |
| Ruby ([gem](https://rubygems.org/)) | [gemnasium](https://gitlab.com/gitlab-org/security-products/gemnasium/general), [bundler-audit](https://github.com/rubysec/bundler-audit) |
| Java ([Maven](https://maven.apache.org/)) | [gemnasium](https://gitlab.com/gitlab-org/security-products/gemnasium/general) |
| PHP ([Composer](https://getcomposer.org/)) | [gemnasium](https://gitlab.com/gitlab-org/security-products/gemnasium/general) |
Some scanners require to send a list of project dependencies to GitLab central servers to check for vulnerabilities. To learn more about this or to disable it please
check [GitLab Dependency Scanning documentation](https://gitlab.com/gitlab-org/security-products/dependency-scanning#remote-checks).
## How it works
First of all, you need to define a job in your `.gitlab-ci.yml` file that generates the
[Dependency Scanning report artifact](../../../ci/yaml/README.md#artifactsreportsdependency_scanning-ultimate).
For more information on how the Dependency Scanning job should look like, check the
example on [Dependency Scanning with GitLab CI/CD](../../../ci/examples/dependency_scanning.md).
GitLab then checks this report, compares the found vulnerabilities between the source and target
branches, and shows the information right on the merge request.
![Dependency Scanning Widget](img/dependency_scanning.png)
This document was moved to [another location](../../application_security/dependency_scanning/index.md).
doc/user/project/merge_requests/index.md
View file @ 3d1be386
......@@ -37,11 +37,11 @@ With **[GitLab Enterprise Edition][ee]**, you can also:
- View the deployment process across projects with [Multi-Project Pipelines](../../../ci/multi_project_pipelines.md) **[PREMIUM]**
- Request [approvals](merge_request_approvals.md) from your managers **[STARTER]**
- Analyze the impact of your changes with [Code Quality reports](code_quality.md) **[STARTER]**
- Manage the licenses of your dependencies with [License Management](#license-management-ultimate) **[ULTIMATE]**
- Analyze your source code for vulnerabilities with [Static Application Security Testing](sast.md) **[ULTIMATE]**
- Analyze your running web applications for vulnerabilities with [Dynamic Application Security Testing](dast.md) **[ULTIMATE]**
- Analyze your dependencies for vulnerabilities with [Dependency Scanning](dependency_scanning.md) **[ULTIMATE]**
- Analyze your Docker images for vulnerabilities with [Container Scanning](container_scanning.md) **[ULTIMATE]**
- Manage the licenses of your dependencies with [License Management](../../application_security/license_management/index.md) **[ULTIMATE]**
- Analyze your source code for vulnerabilities with [Static Application Security Testing](../../application_security/sast/index.md) **[ULTIMATE]**
- Analyze your running web applications for vulnerabilities with [Dynamic Application Security Testing](../../application_security/dast/index.md) **[ULTIMATE]**
- Analyze your dependencies for vulnerabilities with [Dependency Scanning](../../application_security/dependency_scanning/index.md) **[ULTIMATE]**
- Analyze your Docker images for vulnerabilities with [Container Scanning](../../application_security/container_scanning/index.md) **[ULTIMATE]**
- Determine the performance impact of changes with [Browser Performance Testing](#browser-performance-testing-premium) **[PREMIUM]**
## Use cases
......@@ -369,83 +369,11 @@ GitLab runs the [Sitespeed.io container][sitespeed-container] and displays the d
[Read more about Browser Performance Testing.](browser_performance_testing.md)
## License Management **[ULTIMATE]**
> Introduced in [GitLab Ultimate][products] 11.0.
If you are using [GitLab CI/CD][ci], you can search your dependencies for their
licenses using License Management.
Going a step further, GitLab can show the licenses report right in the
merge request widget area.
[Read more about License Management reports.](license_management.md)
## Security reports **[ULTIMATE]**
GitLab can scan and report any vulnerabilities found in your project. The
following security reports are available:
- [Static Application Security Testing reports](sast.md) - Analyze your source
code for known vulnerabilities using Static Application Security Testing (SAST)
and see the security report right in your merge requests.
- [Dynamic Application Security Testing reports](dast.md) - Analyze your running
web application(s) for known vulnerabilities using Dynamic Application Security
Testing (DAST) and see the security report right in your merge requests.
- [Dependency Scanning reports](dependency_scanning.md) - Analyze your
dependencies for known vulnerabilities using Dependency Scanning and see the
security report right in your merge requests.
- [Container Scanning reports](container_scanning.md) - Analyze your Docker
images for known vulnerabilities and see the security report right in your
merge requests.
### Interacting with security reports **[ULTIMATE]**
> Introduced in [GitLab Ultimate][products] 10.8.
CAUTION: **Warning:**
This feature is currently [Alpha](https://about.gitlab.com/handbook/product/#alpha-beta-ga) and while you can start using it, it may receive important changes in the future.
Each security vulnerability in the report is actionable. Clicking on an entry,
a detailed information will pop up with two different possible options:
- **Dismiss vulnerability** - Dismissing a vulnerability will place a <s>strikethrough</s> styling on it.
- **Create issue** - The new issue will have the title and description
pre-populated with the information from the vulnerability report and is created as [confidential](../issues/confidential_issues.md) by default.
- **Solution** - For some vulnerabilities ([Dependency Scanning](dependency_scanning.md) and [Container Scanning](container_scanning.md))
a solution is provided for how to fix the vulnerability.
![Interacting with security reports](img/interactive_reports.png)
You can also revert your dismissal or see the linked issue after the action has
been taken.
### Solutions for Dependency Scanning **[ULTIMATE]**
> Introduced in [GitLab Ultimate][products] 11.7.
CAUTION: **Warning:** Automatic Patch creation is only available for a subset of [Dependency Scanning](dependency_scanning.md). At the moment only Node.JS projects managed with yarn are supported.
Some Vulnerabilities can be fixed by applying a patch that is automatically generated by GitLab. To apply the fix:
1. Download and review the patch file `remediation.patch`.
2. Ensure your local project has the same commit checked out that was used to generate the patch.
3. Run `git apply remediation.patch`.
4. Verify and commit the changes to your branch.
![Solutions for dependency scanning](img/vulnerability_solution.png)
### Create a merge request from a vulnerability **[ULTIMATE]**
> Introduced in [GitLab Ultimate][products] 11.9.
CAUTION: **Warning:** Automatic Patch creation is only available for a subset of [Dependency Scanning](dependency_scanning.md). At the moment only Node.JS projects managed with yarn are supported.
Any vulnerability that has a [solution](#solutions-for-dependency-scanning-ultimate) can have a merge request created to automatically solve the issue.
If this action is available there will be a "Create merge request" button in the vulnerability modal.
Clicking on this button will create a merge request to apply the solution onto the source branch.
GitLab can scan and report any vulnerabilities found in your project.
![Create merge request from vulnerability](img/create-issue-with-list-hover.png)
[Read more about security reports.](../../application_security/index.md)
## Live preview with Review Apps
......
doc/user/project/merge_requests/license_management.md
View file @ 3d1be386
# License Management **[ULTIMATE]**
---
redirect_to: '../../application_security/license_management/index.md'
---
> [Introduced](https://gitlab.com/gitlab-org/gitlab-ee/issues/5483)
in [GitLab Ultimate](https://about.gitlab.com/pricing/) 11.0.
## Overview
If you are using [GitLab CI/CD](../../../ci/README.md), you can search your project dependencies for their licenses
using License Management.
You can take advantage of License Management by either [including the CI job](../../../ci/examples/license_management.md) in
your existing `.gitlab-ci.yml` file or by implicitly using
[Auto License Management](../../../topics/autodevops/index.md#auto-license-management-ultimate)
that is provided by [Auto DevOps](../../../topics/autodevops/index.md).
In addition, you can [manually approve or blacklist](#project-policies-for-license-management) licenses in the project's settings.
Going a step further, GitLab can show the licenses list right in the merge
request widget area, highlighting the presence of licenses you don't want to use, or new
ones that need a decision.
## Use cases
It helps you find what licenses your project uses in its dependencies, and decide for each of then
whether to allow it or forbid it. For example, your application is using an external (open source)
library whose license is incompatible with yours.
## Supported languages and package managers
The following languages and package managers are supported.
| Language | Package managers |
|------------|-------------------------------------------------------------------|
| JavaScript | [Bower](https://bower.io/), [npm](https://www.npmjs.com/) |
| Go | [Godep](https://github.com/tools/godep), go get |
| Java | [Gradle](https://gradle.org/), [Maven](https://maven.apache.org/) |
| .NET | [Nuget](https://www.nuget.org/) |
| Python | [pip](https://pip.pypa.io/en/stable/) |
| Ruby | [gem](https://rubygems.org/) |
## How it works
First of all, you need to define a job in your `.gitlab-ci.yml` file that generates the
[License Management report artifact](../../../ci/yaml/README.md#artifactsreportslicense_management-ultimate).
For more information on how the License Management job should look like, check the
example on [Dependencies license management with GitLab CI/CD](../../../ci/examples/license_management.md).
GitLab then checks this report, compares the licenses between the source and target
branches, and shows the information right on the merge request.
Blacklisted licenses will be clearly visible with an `x` red icon next to them
as well as new licenses which need a decision from you.
NOTE: **Note:**
If the license management report doesn't have anything to compare to, no information
will be displayed in the merge request area. That is the case when you add the
`license_management` job in your `.gitlab-ci.yml` for the first time.
Consecutive merge requests will have something to compare to and the license
management report will be shown properly.
![License Management Widget](img/license_management.png)
If you are a project or group Maintainer, you can click on a license to be given
the choice to approve it or blacklist it.
![License approval decision](img/license_management_decision.png)
### Project policies for license management
> [Introduced](https://gitlab.com/gitlab-org/gitlab-ee/issues/5940)
in [GitLab Ultimate](https://about.gitlab.com/pricing/) 11.4.
From the project's settings:
- The list of licenses and their status can be managed.
- Licenses can be manually approved or blacklisted.
To approve or blacklist a license:
1. Either use the **Manage licenses** button in the merge request widget, or
navigate to the project's **Settings > CI/CD** and expand the
**License Management** section.
1. Click the **Add a license** button.
1. In the **License name** dropdown, either:
- Select one of the available licenses. You can search for licenses in the field
at the top of the list.
- Enter arbitrary text in the field at the top of the list. This will cause the text to be
added as a license name to the list.
1. Select the **Approve** or **Blacklist** radio button to approve or blacklist respectively
the selected license.
![License Management Settings](img/license_management_settings.png)
## License Management report under pipelines
> [Introduced](https://gitlab.com/gitlab-org/gitlab-ee/issues/5491)
in [GitLab Ultimate](https://about.gitlab.com/pricing/) 11.2.
From your project's left sidebar, navigate to **CI/CD > Pipelines** and click on the
pipeline ID that has a `license_management` job to see the Licenses tab with the listed
licenses (if any).
![License Management Pipeline Tab](img/license_management_pipeline_tab.png)
This document was moved to [another location](../../application_security/license_management/index.md).
doc/user/project/merge_requests/sast.md
View file @ 3d1be386
# Static Application Security Testing (SAST) **[ULTIMATE]**
---
redirect_to: '../../application_security/sast/index.md'
---
> [Introduced](https://gitlab.com/gitlab-org/gitlab-ee/issues/3775)
in [GitLab Ultimate](https://about.gitlab.com/pricing/) 10.3.
NOTE: **4 of the top 6 attacks were application based.**
Download our whitepaper,
["A Seismic Shift in Application Security"](https://about.gitlab.com/resources/whitepaper-seismic-shift-application-security/)
to learn how to protect your organization.
## Overview
If you are using [GitLab CI/CD](../../../ci/README.md), you can analyze your source code for known
vulnerabilities using Static Application Security Testing (SAST).
You can take advantage of SAST by either [including the CI job](../../../ci/examples/sast.md) in
your existing `.gitlab-ci.yml` file or by implicitly using
[Auto SAST](../../../topics/autodevops/index.md#auto-sast-ultimate)
that is provided by [Auto DevOps](../../../topics/autodevops/index.md).
Going a step further, GitLab can show the vulnerability list right in the merge
request widget area.
## Use cases
- Your code has a potentially dangerous attribute in a class, or unsafe code
that can lead to unintended code execution.
- Your application is vulnerable to cross-site scripting (XSS) attacks that can
be leveraged to unauthorized access to session data
## Supported languages and frameworks
The following languages and frameworks are supported.
| Language / framework | Scan tool |
|-------------------------|----------------------------------------------------------------------------------------|
| .NET | [Security Code Scan](https://security-code-scan.github.io) |
| C/C++ | [Flawfinder](https://www.dwheeler.com/flawfinder/) |
| Go | [Gosec](https://github.com/securego/gosec) |
| Groovy (Ant, Gradle, Maven and SBT) | [find-sec-bugs](https://find-sec-bugs.github.io/) |
| Java (Ant, Gradle, Maven and SBT) | [find-sec-bugs](https://find-sec-bugs.github.io/) |
| JavaScript | [ESLint security plugin](https://github.com/nodesecurity/eslint-plugin-security) |
| Node.js | [NodeJsScan](https://github.com/ajinabraham/NodeJsScan) |
| PHP | [phpcs-security-audit](https://github.com/FloeDesignTechnologies/phpcs-security-audit) |
| Python | [bandit](https://github.com/PyCQA/bandit) |
| Ruby on Rails | [brakeman](https://brakemanscanner.org) |
| Scala (Ant, Gradle, Maven and SBT) | [find-sec-bugs](https://find-sec-bugs.github.io/) |
| Typescript | [TSLint Config Security](https://github.com/webschik/tslint-config-security/) |
## Secret Detection
GitLab is also able to detect secrets and credentials that have been unintentionally pushed to the repository.
For example, an API key that allows write access to third-party deployment environments.
This check is performed by a specific analyzer during the `sast` job. It runs regardless of the programming
language of your app, and you don't need to change anything to your
CI/CD configuration file to turn it on. Results are available in the SAST report.
GitLab currently includes [Gitleaks](https://github.com/zricethezav/gitleaks) and [TruffleHog](https://github.com/dxa4481/truffleHog) checks.
## How it works
First of all, you need to define a job in your `.gitlab-ci.yml` file that generates the
[SAST report artifact](../../../ci/yaml/README.md#artifactsreportssast-ultimate).
For more information on how the SAST job should look like, check the
example on [Static Application Security Testing with GitLab CI/CD](../../../ci/examples/sast.md).
GitLab then checks this report, compares the found vulnerabilities between the source and target
branches, and shows the information right on the merge request.
![SAST Widget](img/sast.png)
## Security report under pipelines
> [Introduced](https://gitlab.com/gitlab-org/gitlab-ee/issues/3776)
in [GitLab Ultimate](https://about.gitlab.com/pricing) 10.6.
Visit any pipeline page which has a `sast` job and you will be able to see
the security report tab with the listed vulnerabilities (if any).
![Security Report](img/security_report.png)
This document was moved to [another location](../../application_security/sast/index.md).
doc/user/project/merge_requests/sast_docker.md
View file @ 3d1be386
---
redirect_to: 'container_scanning.md'
redirect_to: '../../application_security/container_scanning/index.md'
---
This document was moved to [another location](container_scanning.md).
This document was moved to [another location](../../application_security/container_scanning/index.md).
doc/user/project/security_dashboard.md
View file @ 3d1be386
# Project Security Dashboard **[ULTIMATE]**
---
redirect_to: '../application_security/security_dashboard/index.md'
---
> [Introduced](https://gitlab.com/gitlab-org/gitlab-ee/issues/6165) in [GitLab Ultimate](https://about.gitlab.com/pricing) 11.1.
The Security Dashboard displays the latest security reports for your project.
Use it to find and fix vulnerabilities affecting the [default branch](./repository/branches/index.md#default-branch).
![Project Security Dashboard](img/project_security_dashboard.png)
## How it works?
To benefit from the Security Dashboard you must first configure the [Security Reports](merge_requests/index.md#security-reports-ultimate).
The Security Dashboard will then list security vulnerabilities from the latest pipeline run on the default branch (e.g., `master`).
You will also be able to interact with the reports [the same way you can on a merge request](merge_requests/index.md#interacting-with-security-reports-ultimate).
## Keeping the Security Dashboard updated
The Security Dashboard displays information from the results of the most recent security scan on the default branch. Security scans are performed every time the branch is updated.
If the default branch is updated infrequently, scans are run infrequently and the information on the Security Dashboard can become outdated as new vulnerabilities are discovered.
To ensure the information on the Security Dashboard is regularly updated, configure a [scheduled pipeline](pipelines/schedules.md) to run a daily security scan. This will update the information displayed on the Security Dashboard regardless of how often the default branch is updated.
A daily security scan can be configured to only execute jobs that to relate to security. For more information on configuring security-related jobs, see:
- [Static Application Security Testing](merge_requests/sast.md) and [example](../../ci/examples/sast.md).
- [Dynamic Application Security Testing](merge_requests/dast.md) and [example](../../ci/examples/dast.md).
- [Dependency Scanning](merge_requests/dependency_scanning.md) and [example](../../ci/examples/dependency_scanning.md).
- [Container Scanning](merge_requests/container_scanning.md) and [example](../../ci/examples/container_scanning.md).
### Security scans using Auto DevOps
When using [Auto DevOps](../../topics/autodevops/index.md), use [special environment variables](../../topics/autodevops/index.md#environment-variables) to configure daily security scans.
This document was moved to [another location](../application_security/security_dashboard/index.md).
ee/app/views/groups/security/dashboard/show.html.haml
View file @ 3d1be386
......@@ -5,6 +5,6 @@
vulnerabilities_summary_endpoint: summary_group_security_vulnerabilities_path(@group),
vulnerabilities_history_endpoint: history_group_security_vulnerabilities_path(@group),
projects_endpoint: expose_url(api_v4_groups_projects_path(id: @group.id)),
vulnerability_feedback_help_path: help_page_path("user/project/merge_requests/index", anchor: "interacting-with-security-reports-ultimate"),
vulnerability_feedback_help_path: help_page_path("user/application_security/index", anchor: "interacting-with-the-vulnerabilities"),
empty_state_svg_path: image_path('illustrations/security-dashboard-empty-state.svg'),
dashboard_documentation: help_page_path('user/group/security_dashboard/index') } }
dashboard_documentation: help_page_path('user/application_security/security_dashboard/index') } }
lib/gitlab/ci/templates/Security/Container-Scanning.gitlab-ci.yml
View file @ 3d1be386
# Read more about this feature here: https://docs.gitlab.com/ee/user/project/merge_requests/container_scanning.html
# Read more about this feature here: https://docs.gitlab.com/ee/user/application_security/container_scanning/
container_scanning:
stage: test
......
lib/gitlab/ci/templates/Security/DAST.gitlab-ci.yml
View file @ 3d1be386
# Read more about this feature here: https://docs.gitlab.com/ee/user/project/merge_requests/dast.html
# Read more about this feature here: https://docs.gitlab.com/ee/user/application_security/dast/
# Configure the scanning tool through the environment variables.
# List of the variables: https://gitlab.com/gitlab-org/security-products/dast#settings
......
lib/gitlab/ci/templates/Security/Dependency-Scanning.gitlab-ci.yml
View file @ 3d1be386
# Read more about this feature here: https://docs.gitlab.com/ee/user/project/merge_requests/dependency_scanning.html
# Read more about this feature here: https://docs.gitlab.com/ee/user/application_security/dependency_scanning/
#
# Configure the scanning tool through the environment variables.
# List of the variables: https://gitlab.com/gitlab-org/security-products/dependency-scanning#settings
......
lib/gitlab/ci/templates/Security/License-Management.gitlab-ci.yml
View file @ 3d1be386
# Read more about this feature here: https://docs.gitlab.com/ee/user/project/merge_requests/license_management.html
# Read more about this feature here: https://docs.gitlab.com/ee/user/application_security/license_management/
#
# Configure the scanning tool through the environment variables.
# List of the variables: https://gitlab.com/gitlab-org/security-products/license-management#settings
# How to set: https://docs.gitlab.com/ee/ci/yaml/#variables
variables:
LICENSE_MANAGEMENT_SETUP_CMD: '' # If needed, specify a command to setup your environment with a custom package manager.
......
lib/gitlab/ci/templates/Security/SAST.gitlab-ci.yml
View file @ 3d1be386
# Read more about this feature here: https://docs.gitlab.com/ee/user/project/merge_requests/sast.html
# Read more about this feature here: https://docs.gitlab.com/ee/user/application_security/sast/
#
# Configure the scanning tool through the environment variables.
# List of the variables: https://gitlab.com/gitlab-org/security-products/sast#settings
......
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
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7