diff options
author | GitLab Bot <gitlab-bot@gitlab.com> | 2021-05-14 21:10:34 +0300 |
---|---|---|
committer | GitLab Bot <gitlab-bot@gitlab.com> | 2021-05-14 21:10:34 +0300 |
commit | 7d4b2ed7bf75d316577b718c71a9fdef19184539 (patch) | |
tree | d709e00c4f2ab60901749883f324f9069343037c /doc/user/application_security | |
parent | 7172fb10313a9a7790f8e033b347e77df4987154 (diff) |
Add latest changes from gitlab-org/gitlab@master
Diffstat (limited to 'doc/user/application_security')
-rw-r--r-- | doc/user/application_security/container_scanning/index.md | 39 | ||||
-rw-r--r-- | doc/user/application_security/vulnerabilities/index.md | 2 |
2 files changed, 25 insertions, 16 deletions
diff --git a/doc/user/application_security/container_scanning/index.md b/doc/user/application_security/container_scanning/index.md index 6848126e163..10d276bd224 100644 --- a/doc/user/application_security/container_scanning/index.md +++ b/doc/user/application_security/container_scanning/index.md @@ -501,29 +501,38 @@ For details on saving and transporting Docker images as a file, see Docker's doc #### Automating container scanning vulnerability database updates with a pipeline -For those using Clair, it can be worthwhile to set up a [scheduled pipeline](../../../ci/pipelines/schedules.md) -to build a new version of the vulnerabilities database on a preset schedule. Automating -this with a pipeline means you do not have to do it manually each time. You can use the following -`.gitlab-yml.ci` as a template: +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 +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 +following `.gitlab-yml.ci` example as a template. ```yaml -image: docker:stable +variables: + # If using Clair, uncomment the following 2 lines and comment the Trivy lines below + # SOURCE_IMAGE: arminc/clair-db:latest + # TARGET_IMAGE: $CI_REGISTRY/$CI_PROJECT_PATH/clair-vulnerabilities-db -stages: - - build + # 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 -build_latest_vulnerabilities: - stage: build +image: docker:stable + +update-vulnerabilities-db: services: - - docker:19.03.12-dind + - docker:19-dind script: - - docker pull arminc/clair-db:latest - - docker tag arminc/clair-db:latest $CI_REGISTRY/namespace/clair-vulnerabilities-db - - docker login -u "$CI_REGISTRY_USER" -p "$CI_REGISTRY_PASSWORD" $CI_REGISTRY - - docker push $CI_REGISTRY/namespace/clair-vulnerabilities-db + - docker pull $SOURCE_IMAGE + - docker tag $SOURCE_IMAGE $TARGET_IMAGE + - echo "$CI_REGISTRY_PASSWORD" | docker login $CI_REGISTRY --username $CI_REGISTRY_USER --password-stdin + - docker push $TARGET_IMAGE ``` -The above template works for a GitLab Docker registry running on a local installation, however, if you're using a non-GitLab Docker registry, you need to change the `$CI_REGISTRY` value and the `docker login` credentials to match the details of your local registry. +The above template works for a GitLab Docker registry running on a local installation. However, if +you're using a non-GitLab Docker registry, you must change the `$CI_REGISTRY` value and the +`docker login` credentials to match your local registry's details. ## Running the standalone container scanning tool diff --git a/doc/user/application_security/vulnerabilities/index.md b/doc/user/application_security/vulnerabilities/index.md index b96451fa67d..965b856504d 100644 --- a/doc/user/application_security/vulnerabilities/index.md +++ b/doc/user/application_security/vulnerabilities/index.md @@ -182,7 +182,7 @@ The following vulnerability scanners and their databases are regularly updated: | Secure scanning tool | Vulnerabilities database updates | |:----------------------------------------------------------------|----------------------------------| -| [Container Scanning](../container_scanning/index.md) | Uses `clair`. The latest `clair-db` version is used for each job by running the [`latest` Docker image tag](https://gitlab.com/gitlab-org/gitlab/blob/438a0a56dc0882f22bdd82e700554525f552d91b/lib/gitlab/ci/templates/Security/Container-Scanning.gitlab-ci.yml#L37). The `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) | 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). | | [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. | | [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. | |