Skip to content

G
gitlab-ce
Commit 5bafed1c authored by Olivier Gonzalez's avatar Olivier Gonzalez Committed by Achilleas Pipinellis
Browse files
Options

Document new report types

parent c11d8242
Show whitespace changes
Inline Side-by-side
Showing with 530 additions and 291 deletions
doc/ci/examples/browser_performance.md
View file @ 5bafed1c
# Browser Performance Testing with the Sitespeed.io container # Browser Performance Testing with the Sitespeed.io container
CAUTION: **Caution:**
The job definition shown below is supported on GitLab 11.5 and later versions.
It also requires the GitLab Runner 11.5 or later.
For earlier versions, use the [previous job definitions](#previous-job-definitions).
This example shows how to run the This example shows how to run the
[Sitespeed.io container](https://hub.docker.com/r/sitespeedio/sitespeed.io/) on [Sitespeed.io container](https://hub.docker.com/r/sitespeedio/sitespeed.io/) on
your code by using GitLab CI/CD and [Sitespeed.io](https://www.sitespeed.io) your code by using GitLab CI/CD and [Sitespeed.io](https://www.sitespeed.io)
using Docker-in-Docker. using Docker-in-Docker.
First, you need a GitLab Runner with the First, you need GitLab Runner with
[docker-in-docker executor](../docker/using_docker_build.md#use-docker-in-docker-executor). [docker-in-docker executor](../docker/using_docker_build.md#use-docker-in-docker-executor).
Once you set up the Runner, add a new job to `.gitlab-ci.yml`, called
`performance`: Once you set up the Runner, add a new job to `.gitlab-ci.yml` that
generates the expected report:
```yaml ```yaml
performance: performance:
...@@ -26,19 +32,22 @@ performance: ...@@ -26,19 +32,22 @@ performance:
- mv sitespeed-results/data/performance.json performance.json - mv sitespeed-results/data/performance.json performance.json
artifacts: artifacts:
paths: paths:
- performance.json
- sitespeed-results/ - sitespeed-results/
reports:
performance: performance.json
``` ```
The above example will: The above example will create a `performance` job in your CI/CD pipeline and will run
Sitespeed.io against the webpage you defined in `URL` to gather key metrics.
The [GitLab plugin](https://gitlab.com/gitlab-org/gl-performance) for
Sitespeed.io is downloaded in order to save the report as a
[Performance report artifact](../../ci/yaml/README.md#artifactsreportsperformance)
that you can later download and analyze.
Due to implementation limitations we always take the latest Performance artifact available.
1. Create a `performance` job in your CI/CD pipeline and will run The full HTML Sitespeed.io report will also be saved as an artifact, and if you have
Sitespeed.io against the webpage you defined in `URL`. [GitLab Pages](../../user/project/pages/index.md) enabled, it can be viewed
1. The [GitLab plugin](https://gitlab.com/gitlab-org/gl-performance) for directly in your browser.
Sitespeed.io is downloaded in order to export key metrics to JSON. The full
HTML Sitespeed.io report will also be saved as an artifact, and if you have
[GitLab Pages](../../user/project/pages/index.md) enabled, it can be viewed
directly in your browser.
For further customization options of Sitespeed.io, including the ability to For further customization options of Sitespeed.io, including the ability to
provide a list of URLs to test, please consult provide a list of URLs to test, please consult
...@@ -106,8 +115,40 @@ performance: ...@@ -106,8 +115,40 @@ performance:
- mv sitespeed-results/data/performance.json performance.json - mv sitespeed-results/data/performance.json performance.json
artifacts: artifacts:
paths: paths:
- performance.json
- sitespeed-results/ - sitespeed-results/
reports:
performance: performance.json
``` ```
A complete example can be found in our [Auto DevOps CI YML](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/lib/gitlab/ci/templates/Auto-DevOps.gitlab-ci.yml). A complete example can be found in our [Auto DevOps CI YML](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/lib/gitlab/ci/templates/Auto-DevOps.gitlab-ci.yml).
## Previous job definitions
CAUTION: **Caution:**
Before GitLab 11.5, Performance 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
performance:
stage: performance
image: docker:git
variables:
URL: https://example.com
services:
- docker:stable-dind
script:
- mkdir gitlab-exporter
- wget -O ./gitlab-exporter/index.js https://gitlab.com/gitlab-org/gl-performance/raw/master/index.js
- mkdir sitespeed-results
- docker run --shm-size=1g --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:6.3.1 --plugins.add ./gitlab-exporter --outputFolder sitespeed-results $URL
- mv sitespeed-results/data/performance.json performance.json
artifacts:
paths:
- performance.json
- sitespeed-results/
```
\ No newline at end of file
doc/ci/examples/code_quality.md
View file @ 5bafed1c
# Analyze your project's Code Quality # Analyze your project's Code Quality
CAUTION: **Caution:** CAUTION: **Caution:**
The job definition shown below is supported on GitLab 11.4 and later versions. The job definition shown below is supported on GitLab 11.5 and later versions.
For earlier versions, use the [old job definition](#old-job-definition). It also requires the GitLab Runner 11.5 or later.
For earlier versions, use the [previous job definitions](#previous-job-definitions).
CAUTION: **Caution:**
Code Quality was previously using `codeclimate` and `codequality` for job name and
`codeclimate.json` for the artifact name. While these old names
are still maintained they have been deprecated with GitLab 11.0 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.
This example shows how to run Code Quality on your code by using GitLab CI/CD This example shows how to run Code Quality on your code by using GitLab CI/CD
and Docker. and Docker.
First, you need GitLab Runner with [docker-in-docker executor][dind]. First, you need GitLab Runner with
[docker-in-docker executor](../docker/using_docker_build.md#use-docker-in-docker-executor).
Once you set up the Runner, add a new job to `.gitlab-ci.yml`. Once you set up the Runner, add a new job to `.gitlab-ci.yml` that
generates the expected report:
```yaml ```yaml
code_quality: code_quality:
...@@ -35,29 +31,30 @@ code_quality: ...@@ -35,29 +31,30 @@ code_quality:
"registry.gitlab.com/gitlab-org/security-products/codequality:$SP_VERSION" /code "registry.gitlab.com/gitlab-org/security-products/codequality:$SP_VERSION" /code
artifacts: artifacts:
reports: reports:
codequality: [gl-code-quality-report.json] codequality: gl-code-quality-report.json
``` ```
The above example will create a `code_quality` job in your CI/CD pipeline which The above example will create a `code_quality` job in your CI/CD pipeline which
will scan your source code for code quality issues. The report will be saved will scan your source code for code quality issues. The report will be saved as a
as an artifact that you can later download and analyze. [Code Quality report artifact](../../ci/yaml/README.md#artifactsreportscodequality)
that you can later download and analyze.
Due to implementation limitations we always take the latest Code Quality artifact available.
TIP: **Tip:** TIP: **Tip:**
Starting with [GitLab Starter][ee] 11.4, this information will be automatically For [GitLab Starter][ee] users, this information will be automatically
extracted and shown right in the merge request widget. To do so, the CI/CD job extracted and shown right in the merge request widget.
must have a codequality report artifact. Due to implementation limitations we [Learn more on Code Quality in merge requests](../../user/project/merge_requests/code_quality.html).
always take the latest codequality artifact available.
[Learn more on Code Quality in merge requests](https://docs.gitlab.com/ee/user/project/merge_requests/code_quality.html).
TIP: **Tip:** ## Previous job definitions
Starting with [GitLab Starter][ee] 9.3, this information will
be automatically extracted and shown right in the merge request widget. To do
so, the CI/CD job must be named `code_quality` and the artifact path must be
`gl-code-quality-report.json`.
## Old job definition CAUTION: **Caution:**
Before GitLab 11.5, Code Quality 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.3 and earlier, the job should look like: For GitLab 11.4 and earlier, the job should look like:
```yaml ```yaml
code_quality: code_quality:
...@@ -78,6 +75,10 @@ code_quality: ...@@ -78,6 +75,10 @@ code_quality:
paths: [gl-code-quality-report.json] paths: [gl-code-quality-report.json]
``` ```
Alternatively the job name could be `codeclimate` or `codequality` and the artifact name could be
`codeclimate.json`. These names have been deprecated with GitLab 11.0 and may be removed
in next major release, GitLab 12.0.
For GitLab 10.3 and earlier, the job should look like: For GitLab 10.3 and earlier, the job should look like:
```yaml ```yaml
...@@ -96,5 +97,4 @@ codequality: ...@@ -96,5 +97,4 @@ codequality:
``` ```
[cli]: https://github.com/codeclimate/codeclimate [cli]: https://github.com/codeclimate/codeclimate
[dind]: ../docker/using_docker_build.md#use-docker-in-docker-executor
[ee]: https://about.gitlab.com/pricing/ [ee]: https://about.gitlab.com/pricing/
doc/ci/examples/container_scanning.md
View file @ 5bafed1c
# Container Scanning with GitLab CI/CD # Container Scanning with GitLab CI/CD
CAUTION: **Caution:**
The job definition shown below is supported on GitLab 11.5 and later versions.
It also requires the GitLab Runner 11.5 or later.
For earlier versions, use the [previous job definitions](#previous-job-definitions).
You can check your Docker images (or more precisely the containers) for known You can check your Docker images (or more precisely the containers) for known
vulnerabilities by using [Clair](https://github.com/coreos/clair) and vulnerabilities by using [Clair](https://github.com/coreos/clair) and
[clair-scanner](https://github.com/arminc/clair-scanner), two open source tools [clair-scanner](https://github.com/arminc/clair-scanner), two open source tools
for Vulnerability Static Analysis for containers. for Vulnerability Static Analysis for containers.
All you need is a GitLab Runner with the Docker executor (the shared Runners on First, you need GitLab Runner with
GitLab.com will work fine). You can then add a new job to `.gitlab-ci.yml`, [docker-in-docker executor](../docker/using_docker_build.md#use-docker-in-docker-executor).
called `container_scanning`:
Once you set up the Runner, add a new job to `.gitlab-ci.yml` that
generates the expected report:
```yaml ```yaml
container_scanning: container_scanning:
...@@ -36,32 +43,26 @@ container_scanning: ...@@ -36,32 +43,26 @@ container_scanning:
- 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 - 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 - ./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: artifacts:
paths: [gl-container-scanning-report.json] reports:
container_scanning: gl-container-scanning-report.json
``` ```
The above example will create a `container_scanning` job in your CI/CD pipeline, pull 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) the image from the [Container Registry](../../user/project/container_registry.md)
(whose name is defined from the two `CI_APPLICATION_` variables) and scan it (whose name is defined from the two `CI_APPLICATION_` variables) and scan it
for possible vulnerabilities. The report will be saved as an artifact that you for possible vulnerabilities. The report will be saved as a
can later download and analyze. [Container Scanning report artifact](../../ci/yaml/README.md#artifactsreportscontainer_scanning)
that you can later download and analyze.
Due to implementation limitations we always take the latest Container Scanning artifact available.
If you want to whitelist some specific vulnerabilities, you can do so by defining 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), 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`. in our case its named `clair-whitelist.yml`.
TIP: **Tip:** TIP: **Tip:**
Starting with [GitLab Ultimate][ee] 10.4, this information will For [GitLab Ultimate][ee] users, this information will
be automatically extracted and shown right in the merge request widget. To do be automatically extracted and shown right in the merge request widget.
so, the CI/CD job must be named `container_scanning` and the artifact path must be [Learn more on Container Scanning in merge requests](../../user/project/merge_requests/container_scanning.html).
`gl-container-scanning-report.json`.
[Learn more on container scanning results shown in merge requests](https://docs.gitlab.com/ee/user/project/merge_requests/container_scanning.html).
CAUTION: **Caution:**
Before GitLab 11.0, Container Scanning was previously using `sast:container` for job name and
`gl-sast-container-report.json` for the artifact name. While these old names
are still maintained, they have been deprecated with GitLab 11.0 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.
CAUTION: **Caution:** CAUTION: **Caution:**
Starting with GitLab 11.5, Container Scanning feature is licensed under the name `container_scanning`. Starting with GitLab 11.5, Container Scanning feature is licensed under the name `container_scanning`.
...@@ -69,4 +70,50 @@ While the old name `sast_container` is still maintained, it has been deprecated ...@@ -69,4 +70,50 @@ While the old name `sast_container` is still maintained, it has been deprecated
may be removed in next major release, GitLab 12.0. You are advised to update your current `.gitlab-ci.yml` 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. configuration to reflect that change if you are using the `$GITLAB_FEATURES` environment variable.
## 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-variables-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.1
- 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/ [ee]: https://about.gitlab.com/pricing/
doc/ci/examples/dast.md
View file @ 5bafed1c
# Dynamic Application Security Testing with GitLab CI/CD # Dynamic Application Security Testing with GitLab CI/CD
CAUTION: **Caution:**
The job definition shown below is supported on GitLab 11.5 and later versions.
It also requires the GitLab Runner 11.5 or later.
For earlier versions, use the [previous job definitions](#previous-job-definitions).
[Dynamic Application Security Testing (DAST)](https://en.wikipedia.org/wiki/Dynamic_program_analysis) [Dynamic Application Security Testing (DAST)](https://en.wikipedia.org/wiki/Dynamic_program_analysis)
is using the popular open source tool [OWASP ZAProxy](https://github.com/zaproxy/zaproxy) is using the popular open source tool [OWASP ZAProxy](https://github.com/zaproxy/zaproxy)
to perform an analysis on your running web application. to perform an analysis on your running web application.
...@@ -11,9 +16,11 @@ It can be very useful combined with [Review Apps](../review_apps/index.md). ...@@ -11,9 +16,11 @@ It can be very useful combined with [Review Apps](../review_apps/index.md).
## Example ## Example
All you need is a GitLab Runner with the Docker executor (the shared Runners on First, you need GitLab Runner with
GitLab.com will work fine). You can then add a new job to `.gitlab-ci.yml`, [docker executor](https://docs.gitlab.com/runner/executors/docker.html).
called `dast`:
Once you set up the Runner, add a new job to `.gitlab-ci.yml` that
generates the expected report:
```yaml ```yaml
dast: dast:
...@@ -26,13 +33,16 @@ dast: ...@@ -26,13 +33,16 @@ dast:
- /zap/zap-baseline.py -J gl-dast-report.json -t $website || true - /zap/zap-baseline.py -J gl-dast-report.json -t $website || true
- cp /zap/wrk/gl-dast-report.json . - cp /zap/wrk/gl-dast-report.json .
artifacts: artifacts:
paths: [gl-dast-report.json] reports:
dast: gl-dast-report.json
``` ```
The above example will create a `dast` job in your CI/CD pipeline which will run The above example will create a `dast` job in your CI/CD pipeline which will run
the tests on the URL defined in the `website` variable (change it to use your the tests on the URL defined in the `website` variable (change it to use your
own) and finally write the results in the `gl-dast-report.json` file. You can own) and scan it for possible vulnerabilities. The report will be saved as a
then download and analyze the report artifact in JSON format. [DAST report artifact](../../ci/yaml/README.md#artifactsreportsdast)
that you can later download and analyze.
Due to implementation limitations we always take the latest DAST artifact available.
It's also possible to authenticate the user before performing DAST checks: It's also possible to authenticate the user before performing DAST checks:
...@@ -53,16 +63,40 @@ dast: ...@@ -53,16 +63,40 @@ dast:
--auth-password $password || true --auth-password $password || true
- cp /zap/wrk/gl-dast-report.json . - cp /zap/wrk/gl-dast-report.json .
artifacts: artifacts:
paths: [gl-dast-report.json] reports:
dast: gl-dast-report.json
``` ```
See [zaproxy documentation](https://gitlab.com/gitlab-org/security-products/zaproxy) See [zaproxy documentation](https://gitlab.com/gitlab-org/security-products/zaproxy)
to learn more about authentication settings. to learn more about authentication settings.
TIP: **Tip:** TIP: **Tip:**
Starting with [GitLab Ultimate][ee] 10.4, this information will For [GitLab Ultimate][ee] users, this information will
be automatically extracted and shown right in the merge request widget. To do be automatically extracted and shown right in the merge request widget.
so, the CI job must be named `dast` and the artifact path must be [Learn more on DAST in merge requests](../../user/project/merge_requests/dast.md).
`gl-dast-report.json`.
[Learn more about DAST results shown in merge requests](../../user/project/merge_requests/dast.md). ## 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/ [ee]: https://about.gitlab.com/pricing/
doc/ci/examples/dependency_scanning.md
View file @ 5bafed1c
# Dependency Scanning with GitLab CI/CD **[ULTIMATE]** # Dependency Scanning with GitLab CI/CD **[ULTIMATE]**
CAUTION: **Caution:**
The job definition shown below is supported on GitLab 11.5 and later versions.
It also requires the GitLab Runner 11.5 or later.
For earlier versions, use the [previous job definitions](#previous-job-definitions).
This example shows how to run Dependency Scanning on your This example shows how to run Dependency Scanning on your
project's dependencies by using GitLab CI/CD. project's dependencies by using GitLab CI/CD.
First, you need GitLab Runner with [docker-in-docker executor](https://docs.gitlab.com/ee/ci/docker/using_docker_build.html#use-docker-in-docker-executor).
You can then add a new job to `.gitlab-ci.yml`, called `dependency_scanning`: First, you need GitLab Runner with
[docker-in-docker executor](../docker/using_docker_build.md#use-docker-in-docker-executor).
Once you set up the Runner, add a new job to `.gitlab-ci.yml` that
generates the expected report:
```yaml ```yaml
dependency_scanning: dependency_scanning:
...@@ -22,12 +31,15 @@ dependency_scanning: ...@@ -22,12 +31,15 @@ dependency_scanning:
--volume /var/run/docker.sock:/var/run/docker.sock --volume /var/run/docker.sock:/var/run/docker.sock
"registry.gitlab.com/gitlab-org/security-products/dependency-scanning:$SP_VERSION" /code "registry.gitlab.com/gitlab-org/security-products/dependency-scanning:$SP_VERSION" /code
artifacts: artifacts:
paths: [gl-dependency-scanning-report.json] reports:
dependency_scanning: gl-dependency-scanning-report.json
``` ```
The above example will create a `dependency_scanning` job in the `test` stage and will create the required report artifact. Check the The above example will create a `dependency_scanning` job in your CI/CD pipeline
[Auto-DevOps template](https://gitlab.com/gitlab-org/gitlab-ci-yml/blob/master/Auto-DevOps.gitlab-ci.yml) and scan your dependencies for possible vulnerabilities. The report will be saved as a
for a full reference. [Dependency Scanning report artifact](../../ci/yaml/README.md#artifactsreportsdependency_scanning)
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: The results are sorted by the priority of the vulnerability:
...@@ -45,15 +57,42 @@ central servers to check for vulnerabilities. To learn more about this or to ...@@ -45,15 +57,42 @@ 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). disable it, check the [GitLab Dependency Scanning documentation](https://gitlab.com/gitlab-org/security-products/dependency-scanning#remote-checks).
TIP: **Tip:** TIP: **Tip:**
Starting with [GitLab Ultimate][ee] 10.7, this information will For [GitLab Ultimate][ee] users, this information will
be automatically extracted and shown right in the merge request widget. To do be automatically extracted and shown right in the merge request widget.
so, the CI job must be named `dependency_scanning` and the artifact path must be [Learn more on Dependency Scanning in merge requests](../../user/project/merge_requests/dependency_scanning.md).
`gl-dependency-scanning-report.json`. Make sure your pipeline has a stage nammed `test`,
or specify another existing stage inside the `dependency_scanning` job.
[Learn more on dependency scanning results shown in merge requests](../../user/project/merge_requests/dependency_scanning.md).
## Supported languages and package managers ## 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-frameworks). See [the full list of supported languages and package managers](../../user/project/merge_requests/dependency_scanning.md#supported-languages-and-frameworks).
## 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 SP_VERSION=$(echo "$CI_SERVER_VERSION" | sed 's/^\([0-9]*\)\.\([0-9]*\).*/\1-\2-stable/')
- docker run
--env DEP_SCAN_DISABLE_REMOTE_CHECKS="${DEP_SCAN_DISABLE_REMOTE_CHECKS:-false}"
--volume "$PWD:/code"
--volume /var/run/docker.sock:/var/run/docker.sock
"registry.gitlab.com/gitlab-org/security-products/dependency-scanning:$SP_VERSION" /code
artifacts:
paths: [gl-dependency-scanning-report.json]
```
[ee]: https://about.gitlab.com/pricing/ [ee]: https://about.gitlab.com/pricing/
doc/ci/examples/license_management.md
View file @ 5bafed1c
# Dependencies license management with GitLab CI/CD **[ULTIMATE]** # Dependencies license management with GitLab CI/CD **[ULTIMATE]**
NOTE: **Note:** CAUTION: **Caution:**
In order to use this tool, a [GitLab Ultimate][ee] license The job definition shown below is supported on GitLab 11.5 and later versions.
is needed. It also requires the GitLab Runner 11.5 or later.
For earlier versions, use the [previous job definitions](#previous-job-definitions).
This example shows how to run the License Management tool on your This example shows how to run the License Management tool on your
project's dependencies by using GitLab CI/CD. project's dependencies by using GitLab CI/CD.
You can add a new job to `.gitlab-ci.yml`, called `license_management`: First, you need GitLab Runner with
[docker-in-docker executor](../docker/using_docker_build.md#use-docker-in-docker-executor).
Once you set up the Runner, add a new job to `.gitlab-ci.yml` that
generates the expected report:
```yaml ```yaml
license_management: license_management:
...@@ -19,13 +24,15 @@ license_management: ...@@ -19,13 +24,15 @@ license_management:
script: script:
- /run.sh analyze . - /run.sh analyze .
artifacts: artifacts:
paths: [gl-license-management-report.json] reports:
license_management: gl-license-management-report.json
``` ```
The above example will create a `license_management` job in the `test` stage The above example will create a `license_management` job in your CI/CD pipeline
and will create the required report artifact. Check the [Auto-DevOps and scan your dependencies to find their licenses. The report will be saved as a
template](https://gitlab.com/gitlab-org/gitlab-ci-yml/blob/master/Auto-DevOps.gitlab-ci.yml) [License Management report artifact](../../ci/yaml/README.md#artifactsreportslicense_management)
for a full reference. that you can later download and analyze.
Due to implementation limitations we always take the latest License Management artifact available.
## Install custom project dependencies ## Install custom project dependencies
...@@ -53,18 +60,39 @@ license_management: ...@@ -53,18 +60,39 @@ license_management:
script: script:
- /run.sh analyze . - /run.sh analyze .
artifacts: artifacts:
paths: [gl-license-management-report.json] reports:
license_management: gl-license-management-report.json
``` ```
In this example, `my-custom-install-script.sh` is a shell script at the root of the project. In this example, `my-custom-install-script.sh` is a shell script at the root of the project.
TIP: **Tip:** TIP: **Tip:**
Starting with [GitLab Ultimate][ee] 11.0, this information will For [GitLab Ultimate][ee] users, this information will
be automatically extracted and shown right in the merge request widget. To do be automatically extracted and shown right in the merge request widget.
so, the CI job must be named `license_management` and the artifact path must be [Learn more on License Management in merge requests](../../user/project/merge_requests/license_management.md).
`gl-license-management-report.json`. Make sure your pipeline has a stage named `test`,
or specify another existing stage inside the `license_management` job. ## Previous job definitions
[Learn more on license management results shown in merge requests](../../user/project/merge_requests/license_management.md).
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/ [ee]: https://about.gitlab.com/pricing/
doc/ci/examples/sast.md
View file @ 5bafed1c
# Static Application Security Testing with GitLab CI/CD **[ULTIMATE]** # Static Application Security Testing with GitLab CI/CD **[ULTIMATE]**
CAUTION: **Caution:**
The job definition shown below is supported on GitLab 11.5 and later versions.
It also requires the GitLab Runner 11.5 or later.
For earlier versions, use the [previous job definitions](#previous-job-definitions).
This example shows how to run This example shows how to run
[Static Application Security Testing (SAST)](https://en.wikipedia.org/wiki/Static_program_analysis) [Static Application Security Testing (SAST)](https://en.wikipedia.org/wiki/Static_program_analysis)
on your project's source code by using GitLab CI/CD. on your project's source code by using GitLab CI/CD.
First, you need GitLab Runner with [docker-in-docker executor](https://docs.gitlab.com/ee/ci/docker/using_docker_build.html#use-docker-in-docker-executor). First, you need GitLab Runner with
You can then add a new job to `.gitlab-ci.yml`, called `sast`: [docker-in-docker executor](../docker/using_docker_build.md#use-docker-in-docker-executor).
Once you set up the Runner, add a new job to `.gitlab-ci.yml` that
generates the expected report:
```yaml ```yaml
sast: sast:
...@@ -23,15 +31,19 @@ sast: ...@@ -23,15 +31,19 @@ sast:
--volume /var/run/docker.sock:/var/run/docker.sock --volume /var/run/docker.sock:/var/run/docker.sock
"registry.gitlab.com/gitlab-org/security-products/sast:$SP_VERSION" /app/bin/run /code "registry.gitlab.com/gitlab-org/security-products/sast:$SP_VERSION" /app/bin/run /code
artifacts: artifacts:
paths: [gl-sast-report.json] reports:
sast: gl-sast-report.json
``` ```
The above example will create a `sast` job in the `test` stage and will create the required report artifact. Check the The above example will create a `sast` job in your CI/CD pipeline
[Auto-DevOps template](https://gitlab.com/gitlab-org/gitlab-ci-yml/blob/master/Auto-DevOps.gitlab-ci.yml) and scan your dependencies for possible vulnerabilities. The report will be saved as a
for a full reference. [SAST report artifact](../../ci/yaml/README.md#artifactsreportssast)
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: The results are sorted by the priority of the vulnerability:
1. Critical
1. High 1. High
1. Medium 1. Medium
1. Low 1. Low
...@@ -41,19 +53,43 @@ The results are sorted by the priority of the vulnerability: ...@@ -41,19 +53,43 @@ The results are sorted by the priority of the vulnerability:
Behind the scenes, the [GitLab SAST Docker image](https://gitlab.com/gitlab-org/security-products/sast) 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. is used to detect the languages/frameworks 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 SAST tool documentation](https://gitlab.com/gitlab-org/security-products/sast#remote-checks).
TIP: **Tip:** TIP: **Tip:**
Starting with [GitLab Ultimate][ee] 10.3, this information will For [GitLab Ultimate][ee] users, this information will
be automatically extracted and shown right in the merge request widget. To do be automatically extracted and shown right in the merge request widget.
so, the CI job must be named `sast` and the artifact path must be [Learn more on SAST in merge requests](../../user/project/merge_requests/sast.md).
`gl-sast-report.json`. Make sure your pipeline has a stage nammed `test`, or specify another existing stage inside the `sast` job.
[Learn more on application security testing results shown in merge requests](../../user/project/merge_requests/sast.md).
## Supported languages and frameworks ## Supported languages and frameworks
See [the full list of supported languages and frameworks](../../user/project/merge_requests/sast.md#supported-languages-and-frameworks). See [the full list of supported languages and frameworks](../../user/project/merge_requests/sast.md#supported-languages-and-frameworks).
## 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 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:$SP_VERSION" /app/bin/run /code
artifacts:
paths: [gl-sast-report.json]
```
[ee]: https://about.gitlab.com/pricing/ [ee]: https://about.gitlab.com/pricing/
doc/ci/yaml/README.md
View file @ 5bafed1c
...@@ -1337,6 +1337,81 @@ concatenated into a single file. Use a filename pattern (`junit: rspec-*.xml`), ...@@ -1337,6 +1337,81 @@ concatenated into a single file. Use a filename pattern (`junit: rspec-*.xml`),
an array of filenames (`junit: [rspec-1.xml, rspec-2.xml, rspec-3.xml]`), or a an array of filenames (`junit: [rspec-1.xml, rspec-2.xml, rspec-3.xml]`), or a
combination thereof (`junit: [rspec.xml, test-results/TEST-*.xml]`). combination thereof (`junit: [rspec.xml, test-results/TEST-*.xml]`).
#### `artifacts:reports:codequality`
> Introduced in GitLab 11.5. Requires GitLab Runner 11.5 and above.
The `codequality` report collects [CodeQuality issues](https://docs.gitlab.com/ee/user/project/merge_requests/code_quality.html)
as artifacts.
The collected Code Quality report will be uploaded to GitLab as an artifact and will
be automatically shown in merge requests.
#### `artifacts:reports:sast`
> Introduced in GitLab 11.5. Requires GitLab Runner 11.5 and above.
The `sast` report collects [SAST vulnerabilities](https://docs.gitlab.com/ee/user/project/merge_requests/sast.html)
as artifacts.
The collected SAST report will be uploaded to GitLab as an artifact and will
be automatically shown in merge requests, pipeline view and provide data for security
dashboards.
#### `artifacts:reports:dependency_scanning`
> 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)
as artifacts.
The collected Dependency Scanning report will be uploaded to GitLab as an artifact and will
be automatically shown in merge requests, pipeline view and provide data for security
dashboards.
#### `artifacts:reports:container_scanning`
> 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)
as artifacts.
The collected Container Scanning report will be uploaded to GitLab as an artifact and will
be automatically shown in merge requests, pipeline view and provide data for security
dashboards.
#### `artifacts:reports:dast`
> 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)
as artifacts.
The collected DAST report will be uploaded to GitLab as an artifact and will
be automatically shown in merge requests, pipeline view and provide data for security
dashboards.
#### `artifacts:reports:license_management`
> Introduced in GitLab 11.5. Requires GitLab Runner 11.5 and above.
The `license_management` report collects [Licenses](https://docs.gitlab.com/ee/user/project/merge_requests/license_management.html)
as artifacts.
The collected License Management report will be uploaded to GitLab as an artifact and will
be automatically shown in merge requests, pipeline view and provide data for security
dashboards.
#### `artifacts:reports:performance`
> Introduced in GitLab 11.5. Requires GitLab Runner 11.5 and above.
The `performance` report collects [Performance metrics](https://docs.gitlab.com/ee//user/project/merge_requests/browser_performance_testing.html)
as artifacts.
The collected Performance report will be uploaded to GitLab as an artifact and will
be automatically shown in merge requests.
## `dependencies` ## `dependencies`
> Introduced in GitLab 8.6 and GitLab Runner v1.1.1. > Introduced in GitLab 8.6 and GitLab Runner v1.1.1.
......
doc/user/project/merge_requests/browser_performance_testing.md
View file @ 5bafed1c
# Browser Performance Testing **[PREMIUM]** # Browser Performance Testing **[PREMIUM]**
> [Introduced](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/3507) in [GitLab Premium](https://about.gitlab.com/pricing/) 10.3. > [Introduced](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/3507)
in [GitLab Premium](https://about.gitlab.com/pricing/) 10.3.
## Overview ## Overview
...@@ -19,6 +20,9 @@ is a composite value based on best practices, and we will be expanding support ...@@ -19,6 +20,9 @@ is a composite value based on best practices, and we will be expanding support
for [additional metrics](https://gitlab.com/gitlab-org/gitlab-ee/issues/4370) for [additional metrics](https://gitlab.com/gitlab-org/gitlab-ee/issues/4370)
in a future release. in a future release.
Going a step further, GitLab can show the Performance report right
in the merge request widget area:
## Use cases ## Use cases
For instance, consider the following workflow: For instance, consider the following workflow:
...@@ -32,25 +36,19 @@ For instance, consider the following workflow: ...@@ -32,25 +36,19 @@ For instance, consider the following workflow:
## How it works ## How it works
First of all, you need to define a job named `performance` in your `.gitlab-ci.yml` First of all, you need to define a job in your `.gitlab-ci.yml` file that generates the
file. [Check how the `performance` job should look like](../../../ci/examples/browser_performance.md). [Performance report artifact](../../../ci/yaml/README.md#artifactsreportsperformance).
For more information on how the Performance job should look like, check the
GitLab runs the [Sitespeed.io container](https://hub.docker.com/r/sitespeedio/sitespeed.io/) example on [Testing Browser Performance](../../../ci/examples/browser_performance.md).
and compares key performance metrics for each page between the source and target
branches of a merge request. The difference for each page is then shown right on
the merge request.
In order for the report to show in the merge request, there are two
prerequisites:
- the specified job **must** be named `performance` GitLab then checks this report, compares key performance metrics for each page
- the resulting report **must** be named `performance.json` and uploaded as an between the source and target branches, and shows the information right on the merge request.
artifact
If the performance report doesn't have anything to compare to, no information >**Note:**
If the Performance 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 will be displayed in the merge request area. That is the case when you add the
`performance` job in your `.gitlab-ci.yml` for the very first time. Performance job in your `.gitlab-ci.yml` for the very first time.
Consecutive merge requests will have something to compare to and the performance Consecutive merge requests will have something to compare to and the Performance
report will be shown properly. report will be shown properly.
![Performance Widget](img/browser_performance_testing.png) ![Performance Widget](img/browser_performance_testing.png)
doc/user/project/merge_requests/code_quality.md
View file @ 5bafed1c
# Code Quality **[STARTER]** # Code Quality **[STARTER]**
> [Introduced][ee-1984] in [GitLab Starter][ee] 9.3. > [Introduced](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/1984)
in [GitLab Starter](https://about.gitlab.com/pricing/) 9.3.
## Overview ## Overview
If you are using [GitLab CI/CD][ci], you can analyze your source code quality If you are using [GitLab CI/CD](../../../ci/README.md), you can analyze your
using GitLab Code Quality. Code Quality uses [Code Climate Engines][cc], which are source code quality using GitLab Code Quality.
Code Quality uses [Code Climate Engines](https://codeclimate.com), which are
free and open source. Code Quality doesn’t require a Code Climate subscription. free and open source. Code Quality doesn’t require a Code Climate subscription.
Going a step further, GitLab Code Quality can show the Code Climate report right Going a step further, GitLab can show the Code Quality report right
in the merge request widget area: in the merge request widget area:
![Code Quality Widget][quality-widget] ![Code Quality Widget](img/code_quality.gif)
## Use cases ## Use cases
...@@ -27,32 +29,17 @@ For instance, consider the following workflow: ...@@ -27,32 +29,17 @@ For instance, consider the following workflow:
## How it works ## How it works
In order for the report to show in the merge request, you need to specify a job First of all, you need to define a job in your `.gitlab-ci.yml` file that generates the
that will analyze the code and upload the resulting output JSON as a codequality [Code Quality report artifact](../../../ci/yaml/README.md#artifactsreportscodequality).
report artifact. GitLab will then check this file and show the information For more information on how the Code Quality job should look like, check the
inside the merge request. example on [analyzing a project's code quality](../../../ci/examples/code_quality.md).
GitLab then checks this report, compares the metrics between the source and target
branches, and shows the information right on the merge request.
>**Note:** >**Note:**
If the Code Climate report doesn't have anything to compare to, no information If the Code Quality 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 will be displayed in the merge request area. That is the case when you add the
code quality job in your `.gitlab-ci.yml` for the very first time. Code Quality job in your `.gitlab-ci.yml` for the very first time.
Consecutive merge requests will have something to compare to and the code quality Consecutive merge requests will have something to compare to and the Code Quality
report will be shown properly. report will be shown properly.
For more information on how the code quality job should look like, check the
example on [analyzing a project's code quality with Code Climate CLI][cc-docs].
CAUTION: **Caution:**
Code Quality was previously using `codeclimate` and `codequality` for job name and
`codeclimate.json` for the artifact name. While these old names
are still maintained they have been deprecated with GitLab 11.0 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.
[ee-1984]: https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/1984
[ee]: https://about.gitlab.com/pricing/
[ci]: ../../../ci/README.md
[cc]: https://codeclimate.com
[cd]: https://hub.docker.com/r/codeclimate/codeclimate/
[quality-widget]: img/code_quality.gif
[cc-docs]: ../../../ci/examples/code_quality.md
\ No newline at end of file
doc/user/project/merge_requests/container_scanning.md
View file @ 5bafed1c
# Container Scanning **[ULTIMATE]** # Container Scanning **[ULTIMATE]**
> [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. > [Introduced][ee-3672] in [GitLab Ultimate][ee] 10.4.
## Overview ## Overview
If you are using [GitLab CI/CD][ci], you can analyze your Docker images for known 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), vulnerabilities using [Clair](https://github.com/coreos/clair),
a Vulnerability Static Analysis tool for containers. a Vulnerability Static Analysis tool for containers.
You can take advantage of Container Scanning by either [including the CI job](../../../ci/examples/dependency_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 Going a step further, GitLab can show the vulnerability list right in the merge
request widget area. request widget area.
...@@ -25,28 +33,10 @@ to perform audits for your Docker-based apps. ...@@ -25,28 +33,10 @@ to perform audits for your Docker-based apps.
## How it works ## How it works
In order for the report to show in the merge request, you need to specify a First of all, you need to define a job in your `.gitlab-ci.yml` file that generates the
`container_scanning` job (exact name) that will analyze the code and upload the [Container Scanning report artifact](../../../ci/yaml/README.md#artifactsreportscontainer_scanning).
resulting `gl-container-scanning-report.json` file as an artifact (exact filename). For more information on how the Container Scanning job should look like, check the
GitLab will then check this file and show the information inside the merge request. example on [Container Scanning with GitLab CI/CD](../../../ci/examples/container_scanning.md).
For more information on how the `container_scanning` job should look like, check the GitLab then checks this report, compares the found vulnerabilities between the source and target
example on [analyzing a Docker image for vulnerabilities][cc-docs]. branches, and shows the information right on the merge request.
CAUTION: **Caution:**
Container Scanning was previously using `sast:container` for job name and
`gl-sast-container-report.json` for the artifact name. While these old names
are still maintained they have been deprecated with GitLab 11.0 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.
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.
[ee-3672]: https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/3672
[ee]: https://about.gitlab.com/pricing/
[ci]: ../../../ci/README.md
[cc-docs]: ../../../ci/examples/container_scanning.md
doc/user/project/merge_requests/dast.md
View file @ 5bafed1c
# Dynamic Application Security Testing (DAST) **[ULTIMATE]** # Dynamic Application Security Testing (DAST) **[ULTIMATE]**
> [Introduced][ee-4348] in [GitLab Ultimate][ee] 10.4. > [Introduced](https://gitlab.com/gitlab-org/gitlab-ee/issues/4348)
in [GitLab Ultimate](https://about.gitlab.com/pricing/) 10.4.
If you are using [GitLab CI/CD][ci], you can analyze your running web application(s)
for known vulnerabilities using Dynamic Application Security Testing (DAST).
## Overview ## Overview
...@@ -13,7 +11,10 @@ deployed, your application is exposed to a new category of possible attacks, ...@@ -13,7 +11,10 @@ deployed, your application is exposed to a new category of possible attacks,
such as cross-site scripting or broken authentication flaws. This is where such as cross-site scripting or broken authentication flaws. This is where
Dynamic Application Security Testing (DAST) comes into place. Dynamic Application Security Testing (DAST) comes into place.
You can take advantage of DAST by either [including the CI job][cc-docs] in 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 your existing `.gitlab-ci.yml` file or by implicitly using
[Auto DAST](../../../topics/autodevops/index.md#auto-dast) [Auto DAST](../../../topics/autodevops/index.md#auto-dast)
that is provided by [Auto DevOps](../../../topics/autodevops/index.md). that is provided by [Auto DevOps](../../../topics/autodevops/index.md).
...@@ -28,19 +29,13 @@ applications while you are developing and testing your applications. ...@@ -28,19 +29,13 @@ applications while you are developing and testing your applications.
## How it works ## How it works
First of all, you need to define a job named `dast` in your `.gitlab-ci.yml` First of all, you need to define a job in your `.gitlab-ci.yml` file that generates the
file. [Check how the `dast` job should look like][cc-docs]. [DAST report artifact](../../../ci/yaml/README.md#artifactsreportsdast).
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).
In order for the report to show in the merge request, there are two GitLab then checks this report, compares the found vulnerabilities between the source and target
prerequisites: branches, and shows the information right on the merge request.
- the specified job **must** be named `dast`
- the resulting report **must** be named `gl-dast-report.json` and uploaded as an
artifact
The `dast` job will perform an analysis on the running web application, the
resulting JSON file will be uploaded as an artifact, and GitLab will then check
this file and show the information inside the merge request.
![DAST Widget](img/dast_all.png) ![DAST Widget](img/dast_all.png)
...@@ -48,8 +43,3 @@ By clicking on one of the detected linked vulnerabilities, you will be able to ...@@ -48,8 +43,3 @@ By clicking on one of the detected linked vulnerabilities, you will be able to
see the details and the URL(s) affected. see the details and the URL(s) affected.
![DAST Widget Clicked](img/dast_single.png) ![DAST Widget Clicked](img/dast_single.png)
[ee-4348]: https://gitlab.com/gitlab-org/gitlab-ee/issues/4348
[ee]: https://about.gitlab.com/pricing/
[ci]: ../../../ci/README.md
[cc-docs]: ../../../ci/examples/dast.md
doc/user/project/merge_requests/dependency_scanning.md
View file @ 5bafed1c
# Dependency Scanning **[ULTIMATE]** # Dependency Scanning **[ULTIMATE]**
> [Introduced][ee-5105] in [GitLab Ultimate][ee] 10.7. > [Introduced](https://gitlab.com/gitlab-org/gitlab-ee/issues/5105)
in [GitLab Ultimate][ee] 10.7.
## Overview ## Overview
If you are using [GitLab CI/CD][ci], you can analyze your dependencies for known If you are using [GitLab CI/CD](../../../ci/README.md), you can analyze your dependencies for known
vulnerabilities using Dependency Scanning, either by vulnerabilities using Dependency Scanning.
including the CI job in your [existing `.gitlab-ci.yml` file][cc-docs] or
by implicitly using [Auto Dependency Scanning](../../../topics/autodevops/index.md#auto-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)
that is provided by [Auto DevOps](../../../topics/autodevops/index.md). that is provided by [Auto DevOps](../../../topics/autodevops/index.md).
Going a step further, GitLab can show the vulnerability list right in the merge Going a step further, GitLab can show the vulnerability list right in the merge
...@@ -36,25 +39,12 @@ check [GitLab Dependency Scanning documentation](https://gitlab.com/gitlab-org/s ...@@ -36,25 +39,12 @@ check [GitLab Dependency Scanning documentation](https://gitlab.com/gitlab-org/s
## How it works ## How it works
First of all, you need to define a job named `dependency_scanning` in your First of all, you need to define a job in your `.gitlab-ci.yml` file that generates the
`.gitlab-ci.yml` file. [Check how the `dependency_scanning` job should look like][cc-docs]. [Dependency Scanning report artifact](../../../ci/yaml/README.md#artifactsreportsdependency_scanning).
For more information on how the Dependency Scanning job should look like, check the
In order for the report to show in the merge request, there are two example on [Dependency Scanning with GitLab CI/CD](../../../ci/examples/dependency_scanning.md).
prerequisites:
- the specified job **must** be named `dependency_scanning` GitLab then checks this report, compares the found vulnerabilities between the source and target
- the resulting report **must** be named `gl-dependency-scanning-report.json` branches, and shows the information right on the merge request.
and uploaded as an artifact
The `dependency_scanning` job will perform an analysis on the application
dependencies, the resulting JSON file will be uploaded as an artifact, and
GitLab will then check this file and show the information inside the merge
request.
![Dependency Scanning Widget](img/dependency_scanning.png) ![Dependency Scanning Widget](img/dependency_scanning.png)
[ee-4682]: https://gitlab.com/gitlab-org/gitlab-ee/issues/4682
[ee-5105]: https://gitlab.com/gitlab-org/gitlab-ee/issues/5105
[ee]: https://about.gitlab.com/pricing/
[ci]: ../../../ci/README.md
[cc-docs]: ../../../ci/examples/dependency_scanning.md
doc/user/project/merge_requests/license_management.md
View file @ 5bafed1c
# License Management **[ULTIMATE]** # License Management **[ULTIMATE]**
> [Introduced][ee-5483] in [GitLab Ultimate][ee] 11.0. > [Introduced](https://gitlab.com/gitlab-org/gitlab-ee/issues/5483)
in [GitLab Ultimate](https://about.gitlab.com/pricing/) 11.0.
## Overview ## Overview
If you are using [GitLab CI/CD][ci], you can search your project dependencies for their licenses If you are using [GitLab CI/CD](../../../ci/README.md), you can search your project dependencies for their licenses
using License Management by: using License Management.
- Including the CI job in your [existing `.gitlab-ci.yml` file][cc-docs]. You can take advantage of License Management by either [including the CI job](../../../ci/examples/dependency_scanning.md) in
- Implicitly using [Auto License Management](../../../topics/autodevops/index.md#auto-dependency-scanning) your existing `.gitlab-ci.yml` file or by implicitly using
that is provided by [Auto DevOps](../../../topics/autodevops/index.md). [Auto License Management](../../../topics/autodevops/index.md#auto-license-management)
that is provided by [Auto DevOps](../../../topics/autodevops/index.md).
In addition, you can [manually approve or blacklist](#manual-license-management) licenses in the project's settings. In addition, you can [manually approve or blacklist](#manual-license-management) licenses in the project's settings.
GitLab can show the licenses list right in the merge 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 request widget area, highlighting the presence of licenses you don't want to use, or new
ones that need a decision. ones that need a decision.
...@@ -38,15 +40,15 @@ The following languages and package managers are supported. ...@@ -38,15 +40,15 @@ The following languages and package managers are supported.
## How it works ## How it works
First, you need to define a job named `license_management` in your First of all, you need to define a job in your `.gitlab-ci.yml` file that generates the
`.gitlab-ci.yml` file. [Check how the `license_management` job should look like][cc-docs]. [License Management report artifact](../../../ci/yaml/README.md#artifactsreportslicense_management).
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).
In order for the report to show in the merge request, there are two GitLab then checks this report, compares the licenses between the source and target
prerequisites: branches, and shows the information right on the merge request.
Blacklisted licenses will be clearly visible, as well as new licenses which
- the specified job **must** be named `license_management` need a decision from you.
- the resulting report **must** be named `gl-license-management-report.json`
and uploaded as an artifact
>**Note:** >**Note:**
If the license management report doesn't have anything to compare to, no information If the license management report doesn't have anything to compare to, no information
...@@ -55,12 +57,6 @@ will be displayed in the merge request area. That is the case when you add the ...@@ -55,12 +57,6 @@ will be displayed in the merge request area. That is the case when you add the
Consecutive merge requests will have something to compare to and the license Consecutive merge requests will have something to compare to and the license
management report will be shown properly. management report will be shown properly.
The `license_management` job will search the application dependencies for licenses,
the resulting JSON file will be uploaded as an artifact, and
GitLab will then check this file and show the information inside the merge
request. Blacklisted licenses will be clearly visible, as well as new licenses which
need a decision from you.
![License Management Widget](img/license_management.png) ![License Management Widget](img/license_management.png)
If you are a project or group Maintainer, you can click on a license to be given If you are a project or group Maintainer, you can click on a license to be given
...@@ -77,7 +73,8 @@ From the project's settings: ...@@ -77,7 +73,8 @@ From the project's settings:
### Manual license management ### Manual license management
> [Introduced](https://gitlab.com/gitlab-org/gitlab-ee/issues/5940) in [GitLab Ultimate][ee] 11.4. > [Introduced](https://gitlab.com/gitlab-org/gitlab-ee/issues/5940)
in [GitLab Ultimate](https://about.gitlab.com/pricing/) 11.4.
Licenses can be manually approved or blacklisted in a project's settings. Licenses can be manually approved or blacklisted in a project's settings.
...@@ -95,16 +92,11 @@ To approve or blacklist a license: ...@@ -95,16 +92,11 @@ To approve or blacklist a license:
## License Management report under pipelines ## License Management report under pipelines
> [Introduced][ee-5491] in [GitLab Ultimate][ee] 11.2. > [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 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 pipeline ID that has a `license_management` job to see the Licenses tab with the listed
licenses (if any). licenses (if any).
![License Management Pipeline Tab](img/license_management_pipeline_tab.png) ![License Management Pipeline Tab](img/license_management_pipeline_tab.png)
[ee-5483]: https://gitlab.com/gitlab-org/gitlab-ee/issues/5483
[ee-5491]: https://gitlab.com/gitlab-org/gitlab-ee/issues/5491
[ee]: https://about.gitlab.com/pricing/
[ci]: ../../../ci/README.md
[cc-docs]: ../../../ci/examples/license_management.md
doc/user/project/merge_requests/sast.md
View file @ 5bafed1c
# Static Application Security Testing (SAST) **[ULTIMATE]** # Static Application Security Testing (SAST) **[ULTIMATE]**
> [Introduced][ee-3775] in [GitLab Ultimate][ee] 10.3. > [Introduced](https://gitlab.com/gitlab-org/gitlab-ee/issues/3775)
in [GitLab Ultimate](https://about.gitlab.com/pricing/) 10.3.
## Overview ## Overview
If you are using [GitLab CI/CD][ci], you can analyze your source code for known 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), either by vulnerabilities using Static Application Security Testing (SAST).
including the CI job in your [existing `.gitlab-ci.yml` file][cc-docs] or
by implicitly using [Auto SAST](../../../topics/autodevops/index.md#auto-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)
that is provided by [Auto DevOps](../../../topics/autodevops/index.md). that is provided by [Auto DevOps](../../../topics/autodevops/index.md).
Going a step further, GitLab can show the vulnerability list right in the merge Going a step further, GitLab can show the vulnerability list right in the merge
...@@ -40,33 +43,22 @@ The following languages and frameworks are supported. ...@@ -40,33 +43,22 @@ The following languages and frameworks are supported.
## How it works ## How it works
First of all, you need to define a job named `sast` in your `.gitlab-ci.yml` First of all, you need to define a job in your `.gitlab-ci.yml` file that generates the
file. [Check how the `sast` job should look like][cc-docs]. [SAST report artifact](../../../ci/yaml/README.md#artifactsreportssast).
For more information on how the SAST job should look like, check the
In order for the report to show in the merge request, there are two example on [Static Application Security Testing with GitLab CI/CD](../../../ci/examples/sast.md).
prerequisites:
- the specified job **must** be named `sast` GitLab then checks this report, compares the found vulnerabilities between the source and target
- the resulting report **must** be named `gl-sast-report.json` and uploaded as branches, and shows the information right on the merge request.
an artifact
The `sast` job will perform an analysis on the running web application, the
resulting JSON file will be uploaded as an artifact, and GitLab will then check
this file and show the information inside the merge request.
![SAST Widget](img/sast.png) ![SAST Widget](img/sast.png)
## Security report under pipelines ## Security report under pipelines
> [Introduced][ee-3776] in [GitLab Ultimate][ee] 10.6. > [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 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). the security report tab with the listed vulnerabilities (if any).
![Security Report](img/security_report.png) ![Security Report](img/security_report.png)
[ee-3775]: https://gitlab.com/gitlab-org/gitlab-ee/issues/3775
[ee-3776]: https://gitlab.com/gitlab-org/gitlab-ee/issues/3776
[ee]: https://about.gitlab.com/pricing
[ci]: ../../../ci/README.md
[cc-docs]: ../../../ci/examples/sast.md
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