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
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
[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)
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).
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
performance:
......@@ -26,19 +32,22 @@ performance:
- mv sitespeed-results/data/performance.json performance.json
artifacts:
paths:
- performance.json
- 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
Sitespeed.io against the webpage you defined in `URL`.
1. The [GitLab plugin](https://gitlab.com/gitlab-org/gl-performance) for
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.
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
provide a list of URLs to test, please consult
......@@ -106,8 +115,40 @@ performance:
- mv sitespeed-results/data/performance.json performance.json
artifacts:
paths:
- performance.json
- 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).
## 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
CAUTION: **Caution:**
The job definition shown below is supported on GitLab 11.4 and later versions.
For earlier versions, use the [old job definition](#old-job-definition).
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.
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 Code Quality on your code by using GitLab CI/CD
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
code_quality:
......@@ -35,29 +31,30 @@ code_quality:
"registry.gitlab.com/gitlab-org/security-products/codequality:$SP_VERSION" /code
artifacts:
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
will scan your source code for code quality issues. The report will be saved
as an artifact that you can later download and analyze.
will scan your source code for code quality issues. The report will be saved as a
[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:**
Starting with [GitLab Starter][ee] 11.4, this information will be automatically
extracted and shown right in the merge request widget. To do so, the CI/CD job
must have a codequality report artifact. Due to implementation limitations we
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).
For [GitLab Starter][ee] users, this information will be automatically
extracted and shown right in the merge request widget.
[Learn more on Code Quality in merge requests](../../user/project/merge_requests/code_quality.html).
TIP: **Tip:**
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`.
## Previous job definitions
## 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
code_quality:
......@@ -78,6 +75,10 @@ code_quality:
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:
```yaml
......@@ -96,5 +97,4 @@ codequality:
```
[cli]: https://github.com/codeclimate/codeclimate
[dind]: ../docker/using_docker_build.md#use-docker-in-docker-executor
[ee]: https://about.gitlab.com/pricing/
doc/ci/examples/container_scanning.md
View file @ 5bafed1c
# 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
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.
All you need is a GitLab Runner with the Docker executor (the shared Runners on
GitLab.com will work fine). You can then add a new job to `.gitlab-ci.yml`,
called `container_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
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
- ./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]
reports:
container_scanning: gl-container-scanning-report.json
```
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 an artifact that you
can later download and analyze.
for possible vulnerabilities. The report will be saved as a
[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
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`.
TIP: **Tip:**
Starting with [GitLab Ultimate][ee] 10.4, this information will
be automatically extracted and shown right in the merge request widget. To do
so, the CI/CD job must be named `container_scanning` and the artifact path must be
`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.
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).
CAUTION: **Caution:**
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
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.
## 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/
doc/ci/examples/dast.md
View file @ 5bafed1c
# 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)
is using the popular open source tool [OWASP ZAProxy](https://github.com/zaproxy/zaproxy)
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).
## Example
All you need is a GitLab Runner with the Docker executor (the shared Runners on
GitLab.com will work fine). You can then add a new job to `.gitlab-ci.yml`,
called `dast`:
First, you need GitLab Runner with
[docker executor](https://docs.gitlab.com/runner/executors/docker.html).
Once you set up the Runner, add a new job to `.gitlab-ci.yml` that
generates the expected report:
```yaml
dast:
......@@ -26,13 +33,16 @@ dast:
- /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]
reports:
dast: gl-dast-report.json
```
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
own) and finally write the results in the `gl-dast-report.json` file. You can
then download and analyze the report artifact in JSON format.
own) and scan it for possible vulnerabilities. The report will be saved as a
[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:
......@@ -53,16 +63,40 @@ dast:
--auth-password $password || true
- cp /zap/wrk/gl-dast-report.json .
artifacts:
paths: [gl-dast-report.json]
reports:
dast: gl-dast-report.json
```
See [zaproxy documentation](https://gitlab.com/gitlab-org/security-products/zaproxy)
to learn more about authentication settings.
TIP: **Tip:**
Starting with [GitLab Ultimate][ee] 10.4, this information will
be automatically extracted and shown right in the merge request widget. To do
so, the CI job must be named `dast` and the artifact path must be
`gl-dast-report.json`.
[Learn more about DAST results shown in merge requests](../../user/project/merge_requests/dast.md).
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).
## 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/
doc/ci/examples/dependency_scanning.md
View file @ 5bafed1c
# 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
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
dependency_scanning:
......@@ -22,12 +31,15 @@ dependency_scanning:
--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]
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
[Auto-DevOps template](https://gitlab.com/gitlab-org/gitlab-ci-yml/blob/master/Auto-DevOps.gitlab-ci.yml)
for a full reference.
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)
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:
......@@ -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).
TIP: **Tip:**
Starting with [GitLab Ultimate][ee] 10.7, this information will
be automatically extracted and shown right in the merge request widget. To do
so, the CI job must be named `dependency_scanning` and the artifact path must be
`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).
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).
## 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).
## 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/
doc/ci/examples/license_management.md
View file @ 5bafed1c
# Dependencies license management with GitLab CI/CD **[ULTIMATE]**
NOTE: **Note:**
In order to use this tool, a [GitLab Ultimate][ee] license
is needed.
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 License Management tool on your
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
license_management:
......@@ -19,13 +24,15 @@ license_management:
script:
- /run.sh analyze .
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
and will create the required report artifact. Check the [Auto-DevOps
template](https://gitlab.com/gitlab-org/gitlab-ci-yml/blob/master/Auto-DevOps.gitlab-ci.yml)
for a full reference.
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)
that you can later download and analyze.
Due to implementation limitations we always take the latest License Management artifact available.
## Install custom project dependencies
......@@ -53,18 +60,39 @@ license_management:
script:
- /run.sh analyze .
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.
TIP: **Tip:**
Starting with [GitLab Ultimate][ee] 11.0, this information will
be automatically extracted and shown right in the merge request widget. To do
so, the CI job must be named `license_management` and the artifact path must be
`gl-license-management-report.json`. Make sure your pipeline has a stage named `test`,
or specify another existing stage inside the `license_management` job.
[Learn more on license management results shown in merge requests](../../user/project/merge_requests/license_management.md).
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).
## 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/
doc/ci/examples/sast.md
View file @ 5bafed1c
# 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
[Static Application Security Testing (SAST)](https://en.wikipedia.org/wiki/Static_program_analysis)
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).
You can then add a new job to `.gitlab-ci.yml`, called `sast`:
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
sast:
......@@ -23,15 +31,19 @@ sast:
--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]
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
[Auto-DevOps template](https://gitlab.com/gitlab-org/gitlab-ci-yml/blob/master/Auto-DevOps.gitlab-ci.yml)
for a full reference.
The above example will create a `sast` job in your CI/CD pipeline
and scan your dependencies for possible vulnerabilities. The report will be saved as a
[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:
1. Critical
1. High
1. Medium
1. Low
......@@ -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)
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:**
Starting with [GitLab Ultimate][ee] 10.3, this information will
be automatically extracted and shown right in the merge request widget. To do
so, the CI job must be named `sast` and the artifact path must be
`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).
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).
## 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/
doc/ci/yaml/README.md
View file @ 5bafed1c
......@@ -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
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`
> 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]**
> [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
......@@ -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)
in a future release.
Going a step further, GitLab can show the Performance report right
in the merge request widget area:
## Use cases
For instance, consider the following workflow:
......@@ -32,25 +36,19 @@ For instance, consider the following workflow:
## How it works
First of all, you need to define a job named `performance` in your `.gitlab-ci.yml`
file. [Check how the `performance` job should look like](../../../ci/examples/browser_performance.md).
GitLab runs the [Sitespeed.io container](https://hub.docker.com/r/sitespeedio/sitespeed.io/)
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:
First of all, you need to define a job in your `.gitlab-ci.yml` file that generates the
[Performance report artifact](../../../ci/yaml/README.md#artifactsreportsperformance).
For more information on how the Performance job should look like, check the
example on [Testing Browser Performance](../../../ci/examples/browser_performance.md).
- the specified job **must** be named `performance`
- the resulting report **must** be named `performance.json` and uploaded as an
artifact
GitLab then checks this report, compares key performance metrics for each page
between the source and target branches, and shows the information right on the merge request.
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
`performance` job in your `.gitlab-ci.yml` for the very first time.
Consecutive merge requests will have something to compare to and the performance
Performance job in your `.gitlab-ci.yml` for the very first time.
Consecutive merge requests will have something to compare to and the Performance
report will be shown properly.
![Performance Widget](img/browser_performance_testing.png)
doc/user/project/merge_requests/code_quality.md
View file @ 5bafed1c
# 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
If you are using [GitLab CI/CD][ci], you can analyze your source code quality
using GitLab Code Quality. Code Quality uses [Code Climate Engines][cc], which are
If you are using [GitLab CI/CD](../../../ci/README.md), you can analyze your
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.
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:
![Code Quality Widget][quality-widget]
![Code Quality Widget](img/code_quality.gif)
## Use cases
......@@ -27,32 +29,17 @@ For instance, consider the following workflow:
## How it works
In order for the report to show in the merge request, you need to specify a job
that will analyze the code and upload the resulting output JSON as a codequality
report artifact. GitLab will then check this file and show the information
inside the merge request.
First of all, you need to define a job in your `.gitlab-ci.yml` file that generates the
[Code Quality report artifact](../../../ci/yaml/README.md#artifactsreportscodequality).
For more information on how the Code Quality job should look like, check the
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:**
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
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
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
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]**
> [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], 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),
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
request widget area.
......@@ -25,28 +33,10 @@ to perform audits for your Docker-based apps.
## How it works
In order for the report to show in the merge request, you need to specify a
`container_scanning` job (exact name) that will analyze the code and upload the
resulting `gl-container-scanning-report.json` file as an artifact (exact filename).
GitLab will then check this file and show the information inside the merge request.
For more information on how the `container_scanning` job should look like, check the
example on [analyzing a Docker image for vulnerabilities][cc-docs].
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
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).
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.
doc/user/project/merge_requests/dast.md
View file @ 5bafed1c
# Dynamic Application Security Testing (DAST) **[ULTIMATE]**
> [Introduced][ee-4348] in [GitLab Ultimate][ee] 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).
> [Introduced](https://gitlab.com/gitlab-org/gitlab-ee/issues/4348)
in [GitLab Ultimate](https://about.gitlab.com/pricing/) 10.4.
## Overview
......@@ -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
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
[Auto DAST](../../../topics/autodevops/index.md#auto-dast)
that is provided by [Auto DevOps](../../../topics/autodevops/index.md).
......@@ -28,19 +29,13 @@ applications while you are developing and testing your applications.
## How it works
First of all, you need to define a job named `dast` in your `.gitlab-ci.yml`
file. [Check how the `dast` job should look like][cc-docs].
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).
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
prerequisites:
- 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.
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)
......@@ -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.
![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]**
> [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
If you are using [GitLab CI/CD][ci], you can analyze your dependencies for known
vulnerabilities using Dependency Scanning, either by
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)
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)
that is provided by [Auto DevOps](../../../topics/autodevops/index.md).
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
## How it works
First of all, you need to define a job named `dependency_scanning` in your
`.gitlab-ci.yml` file. [Check how the `dependency_scanning` job should look like][cc-docs].
In order for the report to show in the merge request, there are two
prerequisites:
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).
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).
- the specified job **must** be named `dependency_scanning`
- the resulting report **must** be named `gl-dependency-scanning-report.json`
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.
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)
[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]**
> [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
If you are using [GitLab CI/CD][ci], you can search your project dependencies for their licenses
using License Management by:
If you are using [GitLab CI/CD](../../../ci/README.md), you can search your project dependencies for their licenses
using License Management.
- Including the CI job in your [existing `.gitlab-ci.yml` file][cc-docs].
- Implicitly using [Auto License Management](../../../topics/autodevops/index.md#auto-dependency-scanning)
that is provided by [Auto DevOps](../../../topics/autodevops/index.md).
You can take advantage of License Management by either [including the CI job](../../../ci/examples/dependency_scanning.md) in
your existing `.gitlab-ci.yml` file or by implicitly using
[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.
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
ones that need a decision.
......@@ -38,15 +40,15 @@ The following languages and package managers are supported.
## How it works
First, you need to define a job named `license_management` in your
`.gitlab-ci.yml` file. [Check how the `license_management` job should look like][cc-docs].
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).
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
prerequisites:
- the specified job **must** be named `license_management`
- the resulting report **must** be named `gl-license-management-report.json`
and uploaded as an artifact
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, as well as new licenses which
need a decision from you.
>**Note:**
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
Consecutive merge requests will have something to compare to and the license
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)
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:
### 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.
......@@ -95,16 +92,11 @@ To approve or blacklist a license:
## 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
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)
[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]**
> [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
If you are using [GitLab CI/CD][ci], you can analyze your source code for known
vulnerabilities using Static Application Security Testing (SAST), either by
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)
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)
that is provided by [Auto DevOps](../../../topics/autodevops/index.md).
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.
## How it works
First of all, you need to define a job named `sast` in your `.gitlab-ci.yml`
file. [Check how the `sast` job should look like][cc-docs].
In order for the report to show in the merge request, there are two
prerequisites:
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).
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).
- the specified job **must** be named `sast`
- the resulting report **must** be named `gl-sast-report.json` and uploaded as
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.
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][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
the security report tab with the listed vulnerabilities (if any).
![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