Skip to content

G
gitlab-ce
Commit 6faa1fe1 authored by charlie ablett's avatar charlie ablett
Browse files
Options

Merge branch '331050-make-trivy-the-default-container-scanning-analyzer' into 'master' 

Replace klar with container-scanning

See merge request gitlab-org/gitlab!61850
parents 4cb3eace d3985e67
Show whitespace changes
Inline Side-by-side
Showing with 81 additions and 260 deletions
doc/user/application_security/container_scanning/index.md
View file @ 6faa1fe1
...@@ -10,21 +10,18 @@ info: To determine the technical writer assigned to the Stage/Group associated w ...@@ -10,21 +10,18 @@ info: To determine the technical writer assigned to the Stage/Group associated w
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/3672) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 10.4. > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/3672) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 10.4.
WARNING: WARNING:
GitLab 14.0 will replace its container scanning engine with Trivy. Currently, GitLab uses the open Versions of GitLab prior to 14.0 used Clair as the default container scanning engine. GitLab 14.0
source Clair engine for container scanning. GitLab 13.9 deprecates Clair. Until GitLab 14.0, this is replaces Clair with Trivy and removes Clair from the product. If you run container scanning with the
not a hard breaking change. Beginning in GitLab 14.0, GitLab will no longer update or maintain default settings, GitLab switches you seamlessly and automatically to Trivy in GitLab 14.0. However,
Clair. To ensure that you get regular updates and the latest features, you must use the Trivy if you customized the variables in your container scanning job, you should review the
container scanning engine beginning in GitLab 14.0. See the following sections for instructions on [migration guide](#migrating-from-clair-to-trivy) and make any necessary updates.
moving from Clair to Trivy.
Your application's Docker image may itself be based on Docker images that contain known Your application's Docker image may itself be based on Docker images that contain known
vulnerabilities. By including an extra job in your pipeline that scans for those vulnerabilities and vulnerabilities. By including an extra job in your pipeline that scans for those vulnerabilities and
displays them in a merge request, you can use GitLab to audit your Docker-based apps. displays them in a merge request, you can use GitLab to audit your Docker-based apps.
GitLab provides integration with two different open-source tools for vulnerability static analysis GitLab provides integration with open-source tools for vulnerability static analysis in containers:
in containers:
- [Clair](https://github.com/quay/claircore)
- [Trivy](https://github.com/aquasecurity/trivy) - [Trivy](https://github.com/aquasecurity/trivy)
To integrate GitLab with security scanners other than those listed here, see To integrate GitLab with security scanners other than those listed here, see
...@@ -41,10 +38,6 @@ information directly in the merge request. ...@@ -41,10 +38,6 @@ information directly in the merge request.
![Container Scanning Widget](img/container_scanning_v13_2.png) ![Container Scanning Widget](img/container_scanning_v13_2.png)
<!-- NOTE: The container scanning tool references the following heading in the code, so if you
make a change to this heading, make sure to update the documentation URLs used in the
container scanning tool (https://gitlab.com/gitlab-org/security-products/analyzers/klar) -->
## Requirements ## Requirements
To enable container scanning in your pipeline, you need the following: To enable container scanning in your pipeline, you need the following:
...@@ -53,11 +46,10 @@ To enable container scanning in your pipeline, you need the following: ...@@ -53,11 +46,10 @@ To enable container scanning in your pipeline, you need the following:
or [`kubernetes`](https://docs.gitlab.com/runner/install/kubernetes.html) executor. or [`kubernetes`](https://docs.gitlab.com/runner/install/kubernetes.html) executor.
- Docker `18.09.03` or higher installed on the same computer as the runner. If you're using the - Docker `18.09.03` or higher installed on the same computer as the runner. If you're using the
shared runners on GitLab.com, then this is already the case. shared runners on GitLab.com, then this is already the case.
- An image matching the following supported distributions (depending on the analyzer being used): - An image matching the following supported distributions (depending on the scanner being used):
| Scanning Engine | Supported distributions | | Scanning Engine | Supported distributions |
| --- | --- | | --- | --- |
| [Clair](https://github.com/quay/claircore) | [Supported operating systems and languages](https://quay.github.io/claircore/) |
| [Trivy](https://github.com/aquasecurity/trivy) | Supported [operating systems](https://aquasecurity.github.io/trivy/latest/vuln-detection/os/) and [languages](https://aquasecurity.github.io/trivy/latest/vuln-detection/library/) | | [Trivy](https://github.com/aquasecurity/trivy) | Supported [operating systems](https://aquasecurity.github.io/trivy/latest/vuln-detection/os/) and [languages](https://aquasecurity.github.io/trivy/latest/vuln-detection/library/) |
- [Build and push](../../packages/container_registry/index.md#build-and-push-by-using-gitlab-cicd) - [Build and push](../../packages/container_registry/index.md#build-and-push-by-using-gitlab-cicd)
...@@ -106,6 +98,7 @@ How you enable container scanning depends on your GitLab version: ...@@ -106,6 +98,7 @@ How you enable container scanning depends on your GitLab version:
variable. variable.
- GitLab 13.9 [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/322656) integration with - GitLab 13.9 [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/322656) integration with
[Trivy](https://github.com/aquasecurity/trivy) by upgrading `CS_MAJOR_VERSION` from `3` to `4`. [Trivy](https://github.com/aquasecurity/trivy) by upgrading `CS_MAJOR_VERSION` from `3` to `4`.
- GitLab 14.0 makes Trivy the default scanner.
To include the `Container-Scanning.gitlab-ci.yml` template (GitLab 11.9 and later), add the To include the `Container-Scanning.gitlab-ci.yml` template (GitLab 11.9 and later), add the
following to your `.gitlab-ci.yml` file: following to your `.gitlab-ci.yml` file:
...@@ -164,71 +157,33 @@ The variables you set in your `.gitlab-ci.yml` overwrite those in ...@@ -164,71 +157,33 @@ The variables you set in your `.gitlab-ci.yml` overwrite those in
`Container-Scanning.gitlab-ci.yml`. `Container-Scanning.gitlab-ci.yml`.
This example [includes](../../../ci/yaml/README.md#include) the container scanning template and This example [includes](../../../ci/yaml/README.md#include) the container scanning template and
enables verbose output for both analyzers: enables verbose output for the analyzer:
Clair:
```yaml ```yaml
include: include:
- template: Container-Scanning.gitlab-ci.yml - template: Container-Scanning.gitlab-ci.yml
variables: variables:
CLAIR_TRACE: true SECURE_LOG_LEVEL: 'debug'
``` ```
Trivy:
```yaml
include:
- template: Container-Scanning.gitlab-ci.yml
variables:
TRIVY_DEBUG: true
```
This example [includes](../../../ci/yaml/README.md#include) the container scanning template and
enables version `2` of the analyzer:
```yaml
include:
- template: Container-Scanning.gitlab-ci.yml
variables:
CS_MAJOR_VERSION: '2'
```
<!-- NOTE: The container scanning tool references the following heading in the code, so if you"
make a change to this heading, make sure to update the documentation URLs used in the"
container scanning tool (https://gitlab.com/gitlab-org/security-products/analyzers/klar)" -->
#### Available CI/CD variables #### Available CI/CD variables
You can [configure](#customizing-the-container-scanning-settings) both analyzers by using the following CI/CD variables: You can [configure](#customizing-the-container-scanning-settings) both analyzers by using the following CI/CD variables:
| CI/CD Variable | Default | Description | Supported by| | CI/CD Variable | Default | Description | Scanner |
| ------------------------------ | ------------- | ----------- | ------------ | | ------------------------------ | ------------- | ----------- | ------------ |
| `ADDITIONAL_CA_CERT_BUNDLE` | `""` | Bundle of CA certs that you want to trust. See [Using a custom SSL CA certificate authority](#using-a-custom-ssl-ca-certificate-authority) for more details. | Both | | `ADDITIONAL_CA_CERT_BUNDLE` | `""` | Bundle of CA certs that you want to trust. See [Using a custom SSL CA certificate authority](#using-a-custom-ssl-ca-certificate-authority) for more details. | All |
| `CLAIR_DB_CONNECTION_STRING` | `postgresql://postgres:password@clair-vulnerabilities-db:5432/postgres?sslmode=disable&statement_timeout=60000` | This variable represents the [connection string](https://www.postgresql.org/docs/9.3/libpq-connect.html#AEN39692) to the [PostgreSQL server hosting the vulnerability definitions](https://hub.docker.com/r/arminc/clair-db) database. **Do not change this** unless you're running the image locally as described in [Running the standalone container scanning tool](#running-the-standalone-container-scanning-tool). The host value for the connection string must match the [alias](https://gitlab.com/gitlab-org/gitlab/-/blob/898c5da43504eba87b749625da50098d345b60d6/lib/gitlab/ci/templates/Security/Container-Scanning.gitlab-ci.yml#L23) value of the `Container-Scanning.gitlab-ci.yml` template file, which defaults to `clair-vulnerabilities-db`. | Clair | | `CI_APPLICATION_REPOSITORY` | `$CI_REGISTRY_IMAGE/$CI_COMMIT_REF_SLUG` | Docker repository URL for the image to be scanned. | All |
| `CLAIR_DB_IMAGE` | `arminc/clair-db:latest` | The Docker image name and tag for the [PostgreSQL server hosting the vulnerability definitions](https://hub.docker.com/r/arminc/clair-db). It can be useful to override this value with a specific version (for example, to provide a consistent set of vulnerabilities for integration testing purposes, or to refer to a locally hosted vulnerability database for an on-premise offline installation). | Clair | | `CI_APPLICATION_TAG` | `$CI_COMMIT_SHA` | Docker repository tag for the image to be scanned. | All |
| `CLAIR_DB_IMAGE_TAG` | `latest` | (**DEPRECATED - use `CLAIR_DB_IMAGE` instead**) The Docker image tag for the [PostgreSQL server hosting the vulnerability definitions](https://hub.docker.com/r/arminc/clair-db). It can be useful to override this value with a specific version (for example, to provide a consistent set of vulnerabilities for integration testing purposes). | Clair | | `CS_ANALYZER_IMAGE` | `$SECURE_ANALYZERS_PREFIX/$CS_PROJECT:$CS_MAJOR_VERSION` | Docker image of the analyzer. | All |
| `CLAIR_OUTPUT` | `Unknown` | Severity level threshold. Vulnerabilities with severity level higher than or equal to this threshold are output. Supported levels are `Unknown`, `Negligible`, `Low`, `Medium`, `High`, `Critical`, and `Defcon1`. | Clair | | `DOCKER_IMAGE` | `$CI_APPLICATION_REPOSITORY:$CI_APPLICATION_TAG` | The Docker image to be scanned. If set, this variable overrides the `$CI_APPLICATION_REPOSITORY` and `$CI_APPLICATION_TAG` variables. | All |
| `CLAIR_TRACE` | `"false"` | Set to true to enable more verbose output from the Clair server process. | Clair | | `DOCKER_INSECURE` | `"false"` | Allow access to secure Docker registries using HTTPS without validating the certificates. | All |
| `CLAIR_VULNERABILITIES_DB_URL` | `clair-vulnerabilities-db` | (**DEPRECATED - use `CLAIR_DB_CONNECTION_STRING` instead**) This variable is explicitly set in the [services section](https://gitlab.com/gitlab-org/gitlab/-/blob/898c5da43504eba87b749625da50098d345b60d6/lib/gitlab/ci/templates/Security/Container-Scanning.gitlab-ci.yml#L23) of the `Container-Scanning.gitlab-ci.yml` file and defaults to `clair-vulnerabilities-db`. This value represents the address that the [PostgreSQL server hosting the vulnerability definitions](https://hub.docker.com/r/arminc/clair-db) is running on. **Do not change this** unless you're running the image locally as described in [Running the standalone container scanning tool](#running-the-standalone-container-scanning-tool). | Clair | | `DOCKER_PASSWORD` | `$CI_REGISTRY_PASSWORD` | Password for accessing a Docker registry requiring authentication. | All |
| `CI_APPLICATION_REPOSITORY` | `$CI_REGISTRY_IMAGE/$CI_COMMIT_REF_SLUG` | Docker repository URL for the image to be scanned. | Both | | `DOCKER_USER` | `$CI_REGISTRY_USER` | Username for accessing a Docker registry requiring authentication. | All |
| `CI_APPLICATION_TAG` | `$CI_COMMIT_SHA` | Docker repository tag for the image to be scanned. | Both | | `DOCKERFILE_PATH` | `Dockerfile` | The path to the `Dockerfile` to use for generating remediations. By default, the scanner looks for a file named `Dockerfile` in the root directory of the project. You should configure this variable only if your `Dockerfile` is in a non-standard location, such as a subdirectory. See [Solutions for vulnerabilities](#solutions-for-vulnerabilities-auto-remediation) for more details. | All |
| `CS_ANALYZER_IMAGE` | `$SECURE_ANALYZERS_PREFIX/$CS_PROJECT:$CS_MAJOR_VERSION` | Docker image of the analyzer. | Both | | `REGISTRY_INSECURE` | `"false"` | Allow access to insecure registries (HTTP only). Should only be set to `true` when testing the image locally. | All |
| `CS_MAJOR_VERSION` | `3` | The major version of the Docker image tag. | Both | | `SECURE_LOG_LEVEL` | `info` | Set the minimum logging level. Messages of this logging level or higher are output. From highest to lowest severity, the logging levels are: `fatal`, `error`, `warn`, `info`, `debug`. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/10880) in GitLab 13.1. | All |
| `CS_PROJECT` | Depends on `$CS_MAJOR_VERSION`. `klar` if `$CS_MAJOR_VERSION` is set to `1`, `2` or `3`, and `container-scanning` otherwise. | Analyzer project to be used. | Both |
| `DOCKER_IMAGE` | `$CI_APPLICATION_REPOSITORY:$CI_APPLICATION_TAG` | The Docker image to be scanned. If set, this variable overrides the `$CI_APPLICATION_REPOSITORY` and `$CI_APPLICATION_TAG` variables. | Both |
| `DOCKER_INSECURE` | `"false"` | Allow [Klar](https://github.com/optiopay/klar) to access secure Docker registries using HTTPS with bad (or self-signed) SSL certificates. | Clair |
| `DOCKER_PASSWORD` | `$CI_REGISTRY_PASSWORD` | Password for accessing a Docker registry requiring authentication. | Clair |
| `DOCKER_USER` | `$CI_REGISTRY_USER` | Username for accessing a Docker registry requiring authentication. | Clair |
| `DOCKERFILE_PATH` | `Dockerfile` | The path to the `Dockerfile` to use for generating remediations. By default, the scanner looks for a file named `Dockerfile` in the root directory of the project. You should configure this variable only if your `Dockerfile` is in a non-standard location, such as a subdirectory. See [Solutions for vulnerabilities](#solutions-for-vulnerabilities-auto-remediation) for more details. | Both |
| `KLAR_TRACE` | `"false"` | Set to true to enable more verbose output from Klar. | Clair |
| `REGISTRY_INSECURE` | `"false"` | Allow [Klar](https://github.com/optiopay/klar) to access insecure registries (HTTP only). Should only be set to `true` when testing the image locally. | Clair |
| `SECURE_ANALYZERS_PREFIX` | `"registry.gitlab.com/gitlab-org/security-products/analyzers"` | Set the Docker registry base address from which to download the analyzer. | Both |
| `SECURE_LOG_LEVEL` | `info` | Set the minimum logging level. Messages of this logging level or higher are output. From highest to lowest severity, the logging levels are: `fatal`, `error`, `warn`, `info`, `debug`. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/10880) in GitLab 13.1. | Both |
| `TRIVY_DEBUG` | `"false"` | Set to true to enable more verbose output from the Trivy process. | Trivy |
### Overriding the container scanning template ### Overriding the container scanning template
...@@ -236,18 +191,7 @@ If you want to override the job definition (for example, to change properties li ...@@ -236,18 +191,7 @@ If you want to override the job definition (for example, to change properties li
must declare and override a job after the template inclusion, and then must declare and override a job after the template inclusion, and then
specify any additional keys. specify any additional keys.
This example sets `GIT_STRATEGY` to `fetch` to be considered by both Clair and Trivy: This example sets `GIT_STRATEGY` to `fetch`:
```yaml
include:
- template: Container-Scanning.gitlab-ci.yml
.cs_common:
variables:
GIT_STRATEGY: fetch
```
This example sets `KLAR_TRACE` to `true`, which is specific to Clair:
```yaml ```yaml
include: include:
...@@ -255,18 +199,7 @@ include: ...@@ -255,18 +199,7 @@ include:
container_scanning: container_scanning:
variables: variables:
CLAIR_TRACE: true GIT_STRATEGY: fetch
```
This example sets `TRIVY_DEBUG` to `true`, which is specific to Trivy:
```yaml
include:
- template: Container-Scanning.gitlab-ci.yml
container_scanning_new:
variables:
TRIVY_DEBUG: true
``` ```
WARNING: WARNING:
...@@ -276,36 +209,47 @@ instead. ...@@ -276,36 +209,47 @@ instead.
### Migrating from Clair to Trivy ### Migrating from Clair to Trivy
If you are currently using Clair and want to migrate to Trivy before GitLab 14.0, you can do so by If you're migrating from a GitLab 13.x release to a GitLab 14.x release and have customized the
taking the following steps: `container_scanning` job or its CI variables, you might need to perform these migration steps in
your CI file:
1. Remove these variables:
- `CS_MAJOR_VERSION`
- `CS_PROJECT`
- `SECURE_ANALYZERS_PREFIX`
1. Review the `CS_ANALYZER_IMAGE` variable. It no longer depends on the variables above and its new
default value is `registry.gitlab.com/security-products/container-scanning:4`. If you have an
offline environment, see
[Running container scanning in an offline environment](#running-container-scanning-in-an-offline-environment).
1. If present, remove the `.cs_common` configuration section.
1. Take the following actions in your CI file: 1. If the `container_scanning` section is present, it's safer to create one from scratch based on
the new version of the [`Container-Scanning.gitlab-ci.yml` template](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Security/Container-Scanning.gitlab-ci.yml).
Once finished, it should not have any variables that are only applicable to Klar or Clair. For a
complete list of supported variables, see [available variables](#available-cicd-variables).
- Set the variable `CS_MAJOR_VERSION` to `4`. The job scope is global variables, or under `.cs_common`. 1. Make any [necessary customizations](#customizing-the-container-scanning-settings)
- Remove the variable `CS_PROJECT` from your CI file. The job scope is `container_scanning_new`. to the `Trivy` scanner. We recommend that you minimize such customizations, as they might require
Setting this variable to `container-scanning` under the correct scope has the same effect as changes in future GitLab major releases.
removing it from your CI file.
- Remove the `CS_ANALYZER_IMAGE` variable from your CI file. The job scope is `.cs_common`. Note
that instead of overriding this variable, you can use `CS_MAJOR_VERSION`.
1. Remove any variables that are only applicable to Clair. For a complete list of these variables, 1. Trigger a new run of a pipeline that includes the `container_scanning` job. Inspect the job
see the [available variables](#available-cicd-variables). output and ensure that the log messages do not mention Clair.
1. Make any [necessary customizations](#customizing-the-container-scanning-settings) to the
`Trivy` scanner. We strongly recommended that you minimize customizations, as they
might require changes in future GitLab major releases.
**Troubleshooting** **Troubleshooting**
Prior to the GitLab 14.0 release, any variable defined under the scope `container_scanning` is not Prior to the GitLab 14.0 release, any variable defined under the scope `container_scanning` is not
considered for the Trivy scanner. Verify that all variables for Trivy are considered for the Trivy scanner. Verify that all variables for Trivy are
either defined as a global variable, or under `.cs_common` and `container_scanning_new`. either defined as a global variable, or under `container_scanning`.
### Using a custom SSL CA certificate authority ### Using a custom SSL CA certificate authority
You can use the `ADDITIONAL_CA_CERT_BUNDLE` CI/CD variable to configure a custom SSL CA certificate authority, which is used to verify the peer when fetching Docker images from a registry which uses HTTPS. The `ADDITIONAL_CA_CERT_BUNDLE` value should contain the [text representation of the X.509 PEM public-key certificate](https://tools.ietf.org/html/rfc7468#section-5.1). For example, to configure this value in the `.gitlab-ci.yml` file, use the following: You can use the `ADDITIONAL_CA_CERT_BUNDLE` CI/CD variable to configure a custom SSL CA certificate authority, which is used to verify the peer when fetching Docker images from a registry which uses HTTPS. The `ADDITIONAL_CA_CERT_BUNDLE` value should contain the [text representation of the X.509 PEM public-key certificate](https://tools.ietf.org/html/rfc7468#section-5.1). For example, to configure this value in the `.gitlab-ci.yml` file, use the following:
```yaml ```yaml
.cs_common: container_scanning:
variables: variables:
ADDITIONAL_CA_CERT_BUNDLE: | ADDITIONAL_CA_CERT_BUNDLE: |
-----BEGIN CERTIFICATE----- -----BEGIN CERTIFICATE-----
...@@ -420,8 +364,7 @@ To use container scanning in an offline environment, you need: ...@@ -420,8 +364,7 @@ To use container scanning in an offline environment, you need:
| GitLab Analyzer | Container Registry | | GitLab Analyzer | Container Registry |
| --- | --- | | --- | --- |
| [Klar](https://gitlab.com/gitlab-org/security-products/analyzers/klar/) (used to run Clair) | [Klar container registry](https://gitlab.com/gitlab-org/security-products/analyzers/klar/container_registry) | | [Container-Scanning](https://gitlab.com/gitlab-org/security-products/analyzers/container-scanning) | [Container-Scanning container registry](https://gitlab.com/security-products/container-scanning/container_registry/) |
| [Container-Scanning](https://gitlab.com/gitlab-org/security-products/analyzers/container-scanning) (used to run Trivy) | [Container-Scanning container registry](https://gitlab.com/gitlab-org/security-products/analyzers/container-scanning/container_registry/1741162) |
Note that GitLab Runner has a [default `pull policy` of `always`](https://docs.gitlab.com/runner/executors/docker.html#using-the-always-pull-policy), Note that GitLab Runner has a [default `pull policy` of `always`](https://docs.gitlab.com/runner/executors/docker.html#using-the-always-pull-policy),
meaning the runner tries to pull Docker images from the GitLab container registry even if a local meaning the runner tries to pull Docker images from the GitLab container registry even if a local
...@@ -436,7 +379,6 @@ Support for custom certificate authorities was introduced in the following versi ...@@ -436,7 +379,6 @@ Support for custom certificate authorities was introduced in the following versi
| Scanner | Version | | Scanner | Version |
| -------- | ------- | | -------- | ------- |
| `Clair` | [v2.3.0](https://gitlab.com/gitlab-org/security-products/analyzers/klar/-/releases/v2.3.0) |
| `Trivy` | [4.0.0](https://gitlab.com/gitlab-org/security-products/analyzers/container-scanning/-/releases/4.0.0) | | `Trivy` | [4.0.0](https://gitlab.com/gitlab-org/security-products/analyzers/container-scanning/-/releases/4.0.0) |
#### Make GitLab container scanning analyzer images available inside your Docker registry #### Make GitLab container scanning analyzer images available inside your Docker registry
...@@ -444,17 +386,8 @@ Support for custom certificate authorities was introduced in the following versi ...@@ -444,17 +386,8 @@ Support for custom certificate authorities was introduced in the following versi
For container scanning, import the following default images from `registry.gitlab.com` into your For container scanning, import the following default images from `registry.gitlab.com` into your
[local Docker container registry](../../packages/container_registry/index.md): [local Docker container registry](../../packages/container_registry/index.md):
Clair:
```plaintext
registry.gitlab.com/gitlab-org/security-products/analyzers/klar
https://hub.docker.com/r/arminc/clair-db
```
Trivy:
```plaintext ```plaintext
registry.gitlab.com/gitlab-org/security-products/analyzers/container-scanning registry.gitlab.com/security-products/container-scanning
``` ```
The process for importing Docker images into a local offline Docker registry depends on The process for importing Docker images into a local offline Docker registry depends on
...@@ -473,49 +406,28 @@ For details on saving and transporting Docker images as a file, see Docker's doc ...@@ -473,49 +406,28 @@ For details on saving and transporting Docker images as a file, see Docker's doc
1. [Override the container scanning template](#overriding-the-container-scanning-template) in your `.gitlab-ci.yml` file to refer to the Docker images hosted on your local Docker container registry: 1. [Override the container scanning template](#overriding-the-container-scanning-template) in your `.gitlab-ci.yml` file to refer to the Docker images hosted on your local Docker container registry:
Clair:
```yaml ```yaml
include: include:
- template: Container-Scanning.gitlab-ci.yml - template: Container-Scanning.gitlab-ci.yml
.cs_common: container_scanning:
image: $CI_REGISTRY/namespace/gitlab-klar-analyzer
variables:
CLAIR_DB_IMAGE: $CI_REGISTRY/namespace/clair-vulnerabilities-db
```
Trivy:
```yaml
include:
- template: Container-Scanning.gitlab-ci.yml
.cs_common:
image: $CI_REGISTRY/namespace/gitlab-container-scanning image: $CI_REGISTRY/namespace/gitlab-container-scanning
``` ```
1. If your local Docker container registry is running securely over `HTTPS`, but you're using a 1. If your local Docker container registry is running securely over `HTTPS`, but you're using a
self-signed certificate, then you must set `DOCKER_INSECURE: "true"` in the above self-signed certificate, then you must set `DOCKER_INSECURE: "true"` in the above
`container_scanning` section of your `.gitlab-ci.yml`. This only applies to Clair. `container_scanning` section of your `.gitlab-ci.yml`.
#### Automating container scanning vulnerability database updates with a pipeline #### Automating container scanning vulnerability database updates with a pipeline
We recommend that you set up a [scheduled pipeline](../../../ci/pipelines/schedules.md) We recommend that you set up a [scheduled pipeline](../../../ci/pipelines/schedules.md)
to fetch the latest vulnerabilities database on a preset schedule. Because the Clair scanner is to fetch the latest vulnerabilities database on a preset schedule.
deprecated, the latest vulnerabilities are currently only available for the Trivy scanner.
Automating this with a pipeline means you do not have to do it manually each time. You can use the Automating this with a pipeline means you do not have to do it manually each time. You can use the
following `.gitlab-yml.ci` example as a template. following `.gitlab-yml.ci` example as a template.
```yaml ```yaml
variables: variables:
# If using Clair, uncomment the following 2 lines and comment the Trivy lines below SOURCE_IMAGE: registry.gitlab.com/security-products/container-scanning:4
# SOURCE_IMAGE: arminc/clair-db:latest
# TARGET_IMAGE: $CI_REGISTRY/$CI_PROJECT_PATH/clair-vulnerabilities-db
# If using Trivy, uncomment the following 3 lines and comment the Clair lines above
CS_MAJOR_VERSION: 4 # ensure that this value matches the one you use in your scanning jobs
SOURCE_IMAGE: registry.gitlab.com/gitlab-org/security-products/analyzers/container-scanning:$CS_MAJOR_VERSION
TARGET_IMAGE: $CI_REGISTRY/$CI_PROJECT_PATH/gitlab-container-scanning TARGET_IMAGE: $CI_REGISTRY/$CI_PROJECT_PATH/gitlab-container-scanning
image: docker:stable image: docker:stable
...@@ -536,42 +448,6 @@ you're using a non-GitLab Docker registry, you must change the `$CI_REGISTRY` va ...@@ -536,42 +448,6 @@ you're using a non-GitLab Docker registry, you must change the `$CI_REGISTRY` va
## Running the standalone container scanning tool ## Running the standalone container scanning tool
### Clair
It's possible to run [Klar](https://gitlab.com/gitlab-org/security-products/analyzers/klar)
against a Docker container without needing to run it within the context of a CI job. To scan an
image directly, follow these steps:
1. Run [Docker Desktop](https://www.docker.com/products/docker-desktop) or [Docker Machine](https://github.com/docker/machine).
1. Run the latest [prefilled vulnerabilities database](https://hub.docker.com/repository/docker/arminc/clair-db) Docker image:
```shell
docker run -p 5432:5432 -d --name clair-db arminc/clair-db:latest
```
1. Configure a CI/CD variable to point to your local machine's IP address (or insert your IP address instead of the `LOCAL_MACHINE_IP_ADDRESS` variable in the `CLAIR_DB_CONNECTION_STRING` in the next step):
```shell
export LOCAL_MACHINE_IP_ADDRESS=your.local.ip.address
```
1. Run the analyzer's Docker image, passing the image and tag you want to analyze in the `CI_APPLICATION_REPOSITORY` and `CI_APPLICATION_TAG` variables:
```shell
docker run \
--interactive --rm \
--volume "$PWD":/tmp/app \
-e CI_PROJECT_DIR=/tmp/app \
-e CLAIR_DB_CONNECTION_STRING="postgresql://postgres:password@${LOCAL_MACHINE_IP_ADDRESS}:5432/postgres?sslmode=disable&statement_timeout=60000" \
-e CI_APPLICATION_REPOSITORY=registry.gitlab.com/gitlab-org/security-products/dast/webgoat-8.0@sha256 \
-e CI_APPLICATION_TAG=bc09fe2e0721dfaeee79364115aeedf2174cce0947b9ae5fe7c33312ee019a4e \
registry.gitlab.com/gitlab-org/security-products/analyzers/klar
```
The results are stored in `gl-container-scanning-report.json`.
### Trivy
It's possible to run the [GitLab container scanning tool](https://gitlab.com/gitlab-org/security-products/analyzers/container-scanning) It's possible to run the [GitLab container scanning tool](https://gitlab.com/gitlab-org/security-products/analyzers/container-scanning)
against a Docker container without needing to run it within the context of a CI job. To scan an against a Docker container without needing to run it within the context of a CI job. To scan an
image directly, follow these steps: image directly, follow these steps:
...@@ -589,7 +465,7 @@ image directly, follow these steps: ...@@ -589,7 +465,7 @@ image directly, follow these steps:
-e CI_PROJECT_DIR=/tmp/app \ -e CI_PROJECT_DIR=/tmp/app \
-e CI_APPLICATION_REPOSITORY=registry.gitlab.com/gitlab-org/security-products/dast/webgoat-8.0@sha256 \ -e CI_APPLICATION_REPOSITORY=registry.gitlab.com/gitlab-org/security-products/dast/webgoat-8.0@sha256 \
-e CI_APPLICATION_TAG=bc09fe2e0721dfaeee79364115aeedf2174cce0947b9ae5fe7c33312ee019a4e \ -e CI_APPLICATION_TAG=bc09fe2e0721dfaeee79364115aeedf2174cce0947b9ae5fe7c33312ee019a4e \
registry.gitlab.com/gitlab-org/security-products/analyzers/container-scanning registry.gitlab.com/security-products/container-scanning
``` ```
The results are stored in `gl-container-scanning-report.json`. The results are stored in `gl-container-scanning-report.json`.
......
doc/user/application_security/offline_deployments/index.md
View file @ 6faa1fe1
...@@ -129,6 +129,10 @@ This method requires a runner with access to both `gitlab.com` (including ...@@ -129,6 +129,10 @@ This method requires a runner with access to both `gitlab.com` (including
to be able to use the `docker` command inside the jobs. This runner can be installed in a DMZ or on to be able to use the `docker` command inside the jobs. This runner can be installed in a DMZ or on
a bastion, and used only for this specific project. a bastion, and used only for this specific project.
WARNING:
This template does not include updates for the container scanning analyzer. Please see
[Container scanning offline directions](../container_scanning/index.md#running-container-scanning-in-an-offline-environment).
#### Scheduling the updates #### Scheduling the updates
By default, this project's pipeline runs only once, when the `.gitlab-ci.yml` is added to the By default, this project's pipeline runs only once, when the `.gitlab-ci.yml` is added to the
...@@ -136,12 +140,6 @@ repository. To update the GitLab security scanners and signatures, it's necessar ...@@ -136,12 +140,6 @@ repository. To update the GitLab security scanners and signatures, it's necessar
regularly. GitLab provides a way to [schedule pipelines](../../../ci/pipelines/schedules.md). For regularly. GitLab provides a way to [schedule pipelines](../../../ci/pipelines/schedules.md). For
example, you can set this up to download and store the Docker images every week. example, you can set this up to download and store the Docker images every week.
Some images can be updated more frequently than others. For example, the [vulnerability database](https://hub.docker.com/r/arminc/clair-db/tags)
for Container Scanning is updated daily. To update this single image, create a new Scheduled
Pipeline that runs daily and set `SECURE_BINARIES_ANALYZERS` to `clair-vulnerabilities-db`. Only
this job is triggered, and the image is updated daily and made available in the project
registry.
#### Using the secure bundle created #### Using the secure bundle created
The project using the `Secure-Binaries.gitlab-ci.yml` template should now host all the required The project using the `Secure-Binaries.gitlab-ci.yml` template should now host all the required
......
doc/user/application_security/vulnerabilities/index.md
View file @ 6faa1fe1
...@@ -186,7 +186,7 @@ The following vulnerability scanners and their databases are regularly updated: ...@@ -186,7 +186,7 @@ The following vulnerability scanners and their databases are regularly updated:
| Secure scanning tool | Vulnerabilities database updates | | Secure scanning tool | Vulnerabilities database updates |
|:----------------------------------------------------------------|----------------------------------| |:----------------------------------------------------------------|----------------------------------|
| [Container Scanning](../container_scanning/index.md) | Uses either `trivy` or `clair`. For the `trivy` scanner, a job runs on a daily basis to build a new image with the latest vulnerability database updates from the [upstream `trivy-db`](https://github.com/aquasecurity/trivy-db). For the `clair` scanner, the latest `clair-db` version is used; `clair-db` database [is updated daily according to the author](https://github.com/arminc/clair-local-scan#clair-server-or-local). | | [Container Scanning](../container_scanning/index.md) | A job runs on a daily basis to build new images with the latest vulnerability database updates from the upstream scanner. |
| [Dependency Scanning](../dependency_scanning/index.md) | Relies on `bundler-audit` (for Ruby gems), `retire.js` (for npm packages), and `gemnasium` (the GitLab tool for all libraries). Both `bundler-audit` and `retire.js` fetch their vulnerabilities data from GitHub repositories, so vulnerabilities added to `ruby-advisory-db` and `retire.js` are immediately available. The tools themselves are updated once per month if there's a new version. The [Gemnasium DB](https://gitlab.com/gitlab-org/security-products/gemnasium-db) is updated at least once a week. See our [current measurement of time from CVE being issued to our product being updated](https://about.gitlab.com/handbook/engineering/development/performance-indicators/#cve-issue-to-update). | | [Dependency Scanning](../dependency_scanning/index.md) | Relies on `bundler-audit` (for Ruby gems), `retire.js` (for npm packages), and `gemnasium` (the GitLab tool for all libraries). Both `bundler-audit` and `retire.js` fetch their vulnerabilities data from GitHub repositories, so vulnerabilities added to `ruby-advisory-db` and `retire.js` are immediately available. The tools themselves are updated once per month if there's a new version. The [Gemnasium DB](https://gitlab.com/gitlab-org/security-products/gemnasium-db) is updated at least once a week. See our [current measurement of time from CVE being issued to our product being updated](https://about.gitlab.com/handbook/engineering/development/performance-indicators/#cve-issue-to-update). |
| [Dynamic Application Security Testing (DAST)](../dast/index.md) | The scanning engine is updated on a periodic basis. See the [version of the underlying tool `zaproxy`](https://gitlab.com/gitlab-org/security-products/dast/blob/master/Dockerfile#L1). The scanning rules are downloaded at scan runtime. | | [Dynamic Application Security Testing (DAST)](../dast/index.md) | The scanning engine is updated on a periodic basis. See the [version of the underlying tool `zaproxy`](https://gitlab.com/gitlab-org/security-products/dast/blob/master/Dockerfile#L1). The scanning rules are downloaded at scan runtime. |
| [Static Application Security Testing (SAST)](../sast/index.md) | Relies exclusively on [the tools GitLab wraps](../sast/index.md#supported-languages-and-frameworks). The underlying analyzers are updated at least once per month if a relevant update is available. The vulnerabilities database is updated by the upstream tools. | | [Static Application Security Testing (SAST)](../sast/index.md) | Relies exclusively on [the tools GitLab wraps](../sast/index.md#supported-languages-and-frameworks). The underlying analyzers are updated at least once per month if a relevant update is available. The vulnerabilities database is updated by the upstream tools. |
......
doc/user/application_security/vulnerabilities/severities.md
View file @ 6faa1fe1
...@@ -62,10 +62,9 @@ the following tables: ...@@ -62,10 +62,9 @@ the following tables:
## Container Scanning ## Container Scanning
| GitLab scanner | Outputs severity levels? | Native severity level type | Native severity level example | | GitLab analyzer | Outputs severity levels? | Native severity level type | Native severity level example |
|------------------------------------------------------------------------|--------------------------|----------------------------|--------------------------------------------------------------| |------------------------------------------------------------------------|--------------------------|----------------------------|--------------------------------------------------------------|
| [`clair`](https://gitlab.com/gitlab-org/security-products/analyzers/klar) | **{check-circle}** Yes | String | `Negligible`, `Low`, `Medium`, `High`, `Critical`, `Defcon1` | | [`container-scanning`](https://gitlab.com/gitlab-org/security-products/analyzers/container-scanning)| **{check-circle}** Yes | String | `Unknown`, `Low`, `Medium`, `High`, `Critical` |
| [`trivy`](https://gitlab.com/gitlab-org/security-products/analyzers/container-scanning)| **{check-circle}** Yes | String | `Unknown`, `Low`, `Medium`, `High`, `Critical` |
## Fuzz Testing ## Fuzz Testing
......
ee/spec/lib/gitlab/ci/templates/container_scanning_gitlab_ci_yaml_spec.rb
View file @ 6faa1fe1
...@@ -47,7 +47,7 @@ RSpec.describe 'Container-Scanning.gitlab-ci.yml' do ...@@ -47,7 +47,7 @@ RSpec.describe 'Container-Scanning.gitlab-ci.yml' do
end end
it 'includes job' do it 'includes job' do
expect(build_names).to match_array(%w[container_scanning_new]) expect(build_names).to match_array(%w[container_scanning])
end end
end end
......
lib/gitlab/ci/templates/Security/Container-Scanning.gitlab-ci.yml
View file @ 6faa1fe1
# Use this template to enable container scanning in your project. # Use this template to enable container scanning in your project.
# You should add this template to an existing `.gitlab-ci.yml` file by using the `include:` keyword. # You should add this template to an existing `.gitlab-ci.yml` file by using the `include:`
# keyword.
# The template should work without modifications but you can customize the template settings if # The template should work without modifications but you can customize the template settings if
# needed: https://docs.gitlab.com/ee/user/application_security/container_scanning/#customizing-the-container-scanning-settings # needed: https://docs.gitlab.com/ee/user/application_security/container_scanning/#customizing-the-container-scanning-settings
# #
# Requirements: # Requirements:
# - A `test` stage to be present in the pipeline.
# - You must define the image to be scanned in the DOCKER_IMAGE variable. If DOCKER_IMAGE is the # - You must define the image to be scanned in the DOCKER_IMAGE variable. If DOCKER_IMAGE is the
# same as $CI_APPLICATION_REPOSITORY:$CI_APPLICATION_TAG, you can skip this. # same as $CI_APPLICATION_REPOSITORY:$CI_APPLICATION_TAG, you can skip this.
# - Container registry credentials defined by `DOCKER_USER` and `DOCKER_PASSWORD` variables if the image to be scanned is in a private registry. # - Container registry credentials defined by `DOCKER_USER` and `DOCKER_PASSWORD` variables if the
# image to be scanned is in a private registry.
# - For auto-remediation, a readable Dockerfile in the root of the project or as defined by the # - For auto-remediation, a readable Dockerfile in the root of the project or as defined by the
# DOCKERFILE_PATH variable. # DOCKERFILE_PATH variable.
# #
...@@ -14,59 +17,27 @@ ...@@ -14,59 +17,27 @@
# List of available variables: https://docs.gitlab.com/ee/user/application_security/container_scanning/#available-variables # List of available variables: https://docs.gitlab.com/ee/user/application_security/container_scanning/#available-variables
variables: variables:
# Setting this variable will affect all Security templates (e.g.: SAST, Dependency Scanning) CS_ANALYZER_IMAGE: registry.gitlab.com/security-products/container-scanning:4
SECURE_ANALYZERS_PREFIX: "registry.gitlab.com/gitlab-org/security-products/analyzers"
CS_MAJOR_VERSION: 3 # The major version of the analyzer image to be used for scanning
.cs_common: container_scanning:
stage: test
image: "$CS_ANALYZER_IMAGE" image: "$CS_ANALYZER_IMAGE"
stage: test
variables: variables:
# Override the GIT_STRATEGY variable in your `.gitlab-ci.yml` file and set it to `fetch` if you want to provide a `clair-whitelist.yml` # To provide a `vulnerability-allowlist.yml` file, override the GIT_STRATEGY variable in your
# file. See https://docs.gitlab.com/ee/user/application_security/container_scanning/index.html#overriding-the-container-scanning-template # `.gitlab-ci.yml` file and set it to `fetch`.
# for details # For details, see the following links:
# https://docs.gitlab.com/ee/user/application_security/container_scanning/index.html#overriding-the-container-scanning-template
# https://docs.gitlab.com/ee/user/application_security/container_scanning/#vulnerability-allowlisting
GIT_STRATEGY: none GIT_STRATEGY: none
# CS_ANALYZER_IMAGE is an undocumented variable used internally to allow QA to
# override the analyzer image with a custom value. This may be subject to change or
# breakage across GitLab releases.
CS_ANALYZER_IMAGE: $SECURE_ANALYZERS_PREFIX/$CS_PROJECT:$CS_MAJOR_VERSION
allow_failure: true allow_failure: true
artifacts: artifacts:
reports: reports:
container_scanning: gl-container-scanning-report.json container_scanning: gl-container-scanning-report.json
paths: [gl-container-scanning-report.json]
dependencies: [] dependencies: []
container_scanning:
extends: .cs_common
variables:
# By default, use the latest clair vulnerabilities database, however, allow it to be overridden here with a specific image
# to enable container scanning to run offline, or to provide a consistent list of vulnerabilities for integration testing purposes
CLAIR_DB_IMAGE_TAG: "latest"
CLAIR_DB_IMAGE: "$SECURE_ANALYZERS_PREFIX/clair-vulnerabilities-db:$CLAIR_DB_IMAGE_TAG"
CS_PROJECT: 'klar'
services:
- name: $CLAIR_DB_IMAGE
alias: clair-vulnerabilities-db
script:
- /analyzer run
rules:
- if: $CONTAINER_SCANNING_DISABLED
when: never
- if: $CI_COMMIT_BRANCH &&
$GITLAB_FEATURES =~ /\bcontainer_scanning\b/ &&
$CS_MAJOR_VERSION =~ /^[0-3]$/
container_scanning_new:
extends: .cs_common
variables:
CS_ANALYZER_IMAGE: registry.gitlab.com/security-products/container-scanning:4
script: script:
- gtcs scan - gtcs scan
artifacts:
paths: [gl-container-scanning-report.json]
rules: rules:
- if: $CONTAINER_SCANNING_DISABLED - if: $CONTAINER_SCANNING_DISABLED
when: never when: never
- if: $CI_COMMIT_BRANCH && - if: $GITLAB_FEATURES =~ /\bcontainer_scanning\b/
$GITLAB_FEATURES =~ /\bcontainer_scanning\b/ &&
$CS_MAJOR_VERSION !~ /^[0-3]$/
lib/gitlab/ci/templates/Security/Secure-Binaries.gitlab-ci.yml
View file @ 6faa1fe1
...@@ -15,7 +15,6 @@ variables: ...@@ -15,7 +15,6 @@ variables:
SECURE_BINARIES_ANALYZERS: >- SECURE_BINARIES_ANALYZERS: >-
bandit, brakeman, gosec, spotbugs, flawfinder, phpcs-security-audit, security-code-scan, nodejs-scan, eslint, secrets, sobelow, pmd-apex, kubesec, semgrep, bandit, brakeman, gosec, spotbugs, flawfinder, phpcs-security-audit, security-code-scan, nodejs-scan, eslint, secrets, sobelow, pmd-apex, kubesec, semgrep,
bundler-audit, retire.js, gemnasium, gemnasium-maven, gemnasium-python, bundler-audit, retire.js, gemnasium, gemnasium-maven, gemnasium-python,
klar, clair-vulnerabilities-db,
license-finder, license-finder,
dast, api-fuzzing dast, api-fuzzing
...@@ -161,28 +160,6 @@ kubesec: ...@@ -161,28 +160,6 @@ kubesec:
variables: variables:
- $SECURE_BINARIES_DOWNLOAD_IMAGES == "true" && - $SECURE_BINARIES_DOWNLOAD_IMAGES == "true" &&
$SECURE_BINARIES_ANALYZERS =~ /\bkubesec\b/ $SECURE_BINARIES_ANALYZERS =~ /\bkubesec\b/
#
# Container Scanning jobs
#
klar:
extends: .download_images
only:
variables:
- $SECURE_BINARIES_DOWNLOAD_IMAGES == "true" &&
$SECURE_BINARIES_ANALYZERS =~ /\bklar\b/
variables:
SECURE_BINARIES_ANALYZER_VERSION: "3"
clair-vulnerabilities-db:
extends: .download_images
only:
variables:
- $SECURE_BINARIES_DOWNLOAD_IMAGES == "true" &&
$SECURE_BINARIES_ANALYZERS =~ /\bclair-vulnerabilities-db\b/
variables:
SECURE_BINARIES_IMAGE: arminc/clair-db
SECURE_BINARIES_ANALYZER_VERSION: latest
# #
# Dependency Scanning jobs # Dependency Scanning jobs
......
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