• 概要
  • 機能
• 前提条件
• 設定
  • コンテナスキャン設定のカスタマイズ
    • リモートレジストリ内のイメージのスキャン
      • リ モー ト レ ジ ス ト リ への認証
    • 依存関係リスト
    • 言語特有の調査結果をレポーターが報告
    • 利用可能な CI/CD 変数
  • サポートされるディストリビューション
    • FIPS対応イメージ
  • 自動マージリクエストによるコンテナスキャンの有効化
  • コンテナスキャンテンプレートの上書き
  • スキャナの変更
  • デフォルトブランチイメージの設定
  • カスタムSSL CA認証局の使用
  • 脆弱性許可リスト
    • vulnerability-allowlist.yml データ形式
      • ファイル形式
      • コンテナスキャンジョブのログ形式
  • オフライン環境でのコンテナスキャンの実行
    • オフライン・コンテナ・スキャンの要件
      • カスタム認証局のサポート
    • GitLabコンテナスキャンアナライザーイメージをDockerレジストリ内で利用可能にします。
    • ローカルコンテナスキャナアナライザを使用するためのコンテナスキャンCI/CD変数の設定
    • パイプラインによるコンテナスキャン脆弱性データベース更新の自動化
    • 外部の非公開レジストリ内のイメージをスキャンします。
• スタンドアロンコンテナスキャンツールの実行
• レポートのJSON形式
  • CycloneDXソフトウェア部品表
• セキュリティダッシュボード
• 脆弱性データベース
• 脆弱性との対話
• 脆弱性の解決（自動修復）
• トラブルシューティング
  • docker: Error response from daemon: failed to copy xattrs
  • 警告メッセージgl-container-scanning-report.json: no matching files
• 変更点

コンテナスキャン

• CS_MAJOR_VERSION を2 から3にアップグレードすることで、GitLab 13.6 で導入されたFIPS のサポートを改善しました。
• CS_MAJOR_VERSION を3 から4にアップグレードすることで、GitLab 13.9 で導入された Trivy とのインテグレーション。
• ClairとのインテグレーションはGitLab 13.9で非推奨となりました。
• GitLab 14.0でTrivyによるデフォルトコンテナスキャンを導入。
• GitLab 14.0で導入された代替スキャナとしてのGrypeとのインテグレーション。
• GitLab 15.0で、アナライザーのメジャーバージョンを4 から5 に変更しました。
• GitLab 15.0でGitLab UltimateからGitLab Freeへ移行。
• GitLab 15.4でDockerを参照するコンテナスキャン変数の名前を変更。
• GitLab 15.6でコンテナスキャニングのテンプレートがSecurity/Container-Scanning.gitlab-ci.yml からJobs/Container-Scanning.gitlab-ci.yml に移動しました。

あなたのアプリケーションのDockerイメージ自体が、既知の脆弱性を含むDockerイメージをベースにしているかもしれません。これらの脆弱性をスキャンしてマージリクエストに表示するコンテナスキャニングジョブをパイプラインに追加することで、GitLabを使ってDockerベースのアプリを監査することができます。

概要については、コンテナスキャンを参照してください。

コンテナスキャンは、ソフトウェア構成分析（Software Composition Analysis）(SCA)。SCA には、コードが使用するアイテムの検査という側面があります。これらの項目には、通常、アプリケーションやシステムの依存関係が含まれます。これらの依存関係は、ほとんどの場合、自分で書いた項目からではなく、外部ソースからインポートされます。

GitLabはコンテナスキャンと依存関係スキャンの両方を提供し、これらの依存関係の種類すべてを確実にカバーします。可能な限り多くのリスク領域をカバーするために、私たちのセキュリティスキャナをすべて使うことをお勧めします。これらの機能の比較については、コンテナスキャンと比較した依存関係スキャンをご覧ください。

概要

GitLabはコンテナにおける脆弱性静的解析のためのオープンソースツールとインテグレーションします：

• Trivy
• グライプ

ここに挙げた以外のセキュリティスキャナとGitLabをインテグレーションするには、セキュリティスキャナのインテグレーションをご覧ください。

コンテナスキャンを有効にするには、以下のいずれかの方法を実行します：

• 既存の.gitlab-ci.yml ファイルにCI ジョブを含めます。
• Auto DevOpsが提供するAuto Container Scanningを暗黙的に使用します。

GitLab は発見された脆弱性をソースブランチとターゲットブランチの間で比較し、マージリクエストにその情報を直接表示します。

機能

前提条件

パイプラインでコンテナスキャンを有効にするには、以下が必要です：

• GitLab CI/CD パイプラインにはtest ステージが含まれている必要があります。このステージはstages キーワードで上書きしない限り利用可能です。
• GitLab RunnerはLinux/amd64上でdocker またはkubernetes Executorを使用します。
• Docker18.09.03 またはそれ以降がRunnerと同じコンピュータにインストールされていること。GitLab.comの共有Runnerを使っているのであれば、これは既にそうなっています。
• サポートされているディストリビューションに一致するイメージ。
• Dockerイメージをビルドし、プロジェクトのコンテナレジストリにプッシュします。
• サードパーティのコンテナレジストリを使用している場合は、CS_REGISTRY_USER とCS_REGISTRY_PASSWORD 設定変数で認証情報を提供する必要があるかもしれません。これらの変数の使用方法の詳細については、リモートレジストリへの認証を参照してください。

設定

コンテナ・スキャンを有効にするには、.gitlab-ci.yml ファイルにContainer-Scanning.gitlab-ci.yml テンプレート を追加します：

include:
  - template: Security/Container-Scanning.gitlab-ci.yml

含まれているテンプレート：

• CI/CD パイプラインにcontainer_scanning ジョブを作成します。
• プロジェクトのコンテナレジストリからビルドされたDockerイメージを取得し（前提条件を参照）、脆弱性の可能性がないかスキャンします。

GitLabは結果をコンテナスキャンレポートアーティファクトとして保存し、後でダウンロードして分析することができます。ダウンロードする際は、常に最新のアーティファクトを受け取ります。依存関係スキャンが有効な場合、依存関係スキャンレポートアーティファクトも作成されます。

以下は、Dockerイメージをビルドし、コンテナレジストリにプッシュし、イメージをスキャンするサンプル.gitlab-ci.yml ：

include:
  - template: Jobs/Build.gitlab-ci.yml
  - template: Security/Container-Scanning.gitlab-ci.yml

container_scanning:
  variables:
    CS_DEFAULT_BRANCH_IMAGE: $CI_REGISTRY_IMAGE/$CI_DEFAULT_BRANCH:$CI_COMMIT_SHA

この設定により、CS_DEFAULT_BRANCH_IMAGE ブランチ間でイメージ名が異なる場合に脆弱性が重複して発見されることを回避 CS_DEFAULT_BRANCH_IMAGEできます。CS_DEFAULT_BRANCH_IMAGE の値は CS_DEFAULT_BRANCH_IMAGE、デフォルトのブランチに表示されるスキャンされたイメージの名前を示します。この重複排除の実現方法の詳細については、デフォルトブランチイメージの設定を参照してください。

コンテナスキャン設定のカスタマイズ

GitLabがコンテナをスキャンする方法をカスタマイズしたい場合があるかもしれません。例えば、より冗長な出力を有効にしたり、認証が必要なDockerレジストリにアクセスしたり、などです。このような設定を変更するには、variables パラメータを使って.gitlab-ci.yml CI/CD 変数を設定 .gitlab-ci.ymlします。.gitlab-ci.yml yourで設定した変数は .gitlab-ci.yml、Container-Scanning.gitlab-ci.ymlで設定したものを上書きします。

この例では、コンテナスキャンテンプレートを含め、アナライザの冗長出力を有効にしています：

include:
  - template: Security/Container-Scanning.gitlab-ci.yml

variables:
    SECURE_LOG_LEVEL: 'debug'

リモートレジストリ内のイメージのスキャン

プ ロ ジ ェ ク ト の レ ジ ス ト リ 以外の レ ジ ス ト リ 内にあ る 画像を ス キ ャ ンす る には、 以下.gitlab-ci.yml を使用 し ます：

include:
  - template: Security/Container-Scanning.gitlab-ci.yml

container_scanning:
  variables:
    CS_IMAGE: example.com/user/image:tag

リ モー ト レ ジ ス ト リ への認証

非公開レジストリ内の画像をスキャンするには認証が必要です。変数CS_REGISTRY_USER にユーザー名を、設定変数CS_REGISTRY_PASSWORD にパスワードを指定します。

たとえば、AWS Elastic Container Registry からイメージをスキャンするには、次のようにします：

container_scanning:
  before_script:
    - ruby -r open-uri -e "IO.copy_stream(URI.open('https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip'), 'awscliv2.zip')"
    - unzip awscliv2.zip
    - sudo ./aws/install
    - aws --version
    - export AWS_ECR_PASSWORD=$(aws ecr get-login-password --region region)

include:
  - template: Security/Container-Scanning.gitlab-ci.yml

variables:
    CS_IMAGE: <aws_account_id>.dkr.ecr.<region>.amazonaws.com/<image>:<tag>
    CS_REGISTRY_USER: AWS
    CS_REGISTRY_PASSWORD: "$AWS_ECR_PASSWORD"

FIPS モードが有効な場合、リモートレジストリへの認証はサポートされません。

依存関係リスト

GitLab 14.6で導入されました。

CS_DISABLE_DEPENDENCY_LIST CI/CD 変数は、スキャンがDependency Listレポートを作成するかどうかを制御します。この変数は現在、trivy アナライザーを使用する場合にのみサポートされています。変数のデフォルト設定"false" では、スキャンがレポートを作成します。レポートを無効にするには、変数を"true"に設定します：

使用例：

include:
  - template: Security/Container-Scanning.gitlab-ci.yml

container_scanning:
  variables:
    CS_DISABLE_DEPENDENCY_LIST: "true"

言語特有の調査結果をレポーターが報告

GitLab 14.6で導入されました。

CS_DISABLE_LANGUAGE_VULNERABILITY_SCAN CI/CD 変数は、スキャンがプログラミング言語に関する発見をレポーターするかどうかを制御します。サポートされる言語は使用するスキャナによって異なります：

• Trivy
• Grype。

デフォルトでは、レポートにはオペレーティングシステム(OS) パッケージマネージャが管理するパッケージのみが含まれます（例えば、yum,apt,apk,tdnf）。OS 以外のパッケージで発見されたセキュリティをレポートするには、CS_DISABLE_LANGUAGE_VULNERABILITY_SCAN を"false"に設定してください：

include:
  - template: Security/Container-Scanning.gitlab-ci.yml

container_scanning:
  variables:
    CS_DISABLE_LANGUAGE_VULNERABILITY_SCAN: "false"

この機能を有効にすると、プロジェクトで依存性スキャンが有効になっている場合、脆弱性レポートに重複した発見が表示されることがあります。これは、GitLabが異なる種類のスキャンツール間で発見を自動的に重複排除できないために起こります。どのタイプの依存関係が重複しやすいかを理解するには、コンテナスキャンと比較した依存関係スキャンを参照してください。

利用可能な CI/CD 変数

以下のCI/CD変数を使ってアナライザーを設定できます。

サポートされるディストリビューション

どのスキャナーを使用するかによってサポートが異なります：

FIPS対応イメージ

GitLab 14.1 で導入されました。

GitLab はFIPS 対応の Red Hat UBIバージョンのコンテナスキャンイメージも提供しています。そのため、標準イメージを FIPS 対応イメージに置き換えることができます。イメージを設定するには、CS_IMAGE_SUFFIX を-fips に設定するか、CS_ANALYZER_IMAGE 変数を標準タグに-fips 拡張を加えたものに変更します。

GitLab 14.10から、GitLabインスタンスでFIPSモードが有効になっている場合、CS_ANALYZER_IMAGE に-fips が自動的に追加されます。

FIPSモードが有効な場合、認証済みレジストリ内のイメージのコンテナスキャンはサポートされません。CI_GITLAB_FIPS_MODE が"true" で、CS_REGISTRY_USER またはCS_REGISTRY_PASSWORD が設定されている場合、アナライザーはエラーで終了し、スキャンは実行されません。

自動マージリクエストによるコンテナスキャンの有効化

GitLab 14.9で導入されました。

プロジェクトでコンテナスキャンを有効にするには、セキュリティ設定ページからマージリクエストを作成してください：

1. コンテナ・スキャンを有効にするプロジェクトで、Secure > Security configuration に進みます。
2. コンテナ・スキャンの行で、マージリクエストで設定するを選択します。

これにより、コンテナスキャンを有効にするために必要な変更を含むマージリクエストが自動的に作成されます。設定を完了するには、このマージリクエストをレビューしてマージします。

設定ツールは、.gitlab-ci.yml ファイルが存在しないか、最小限の設定ファイルで最適に動作します。複雑なGitLab設定ファイルがある場合、正常に解析されずエラーが発生することがあります。

コンテナスキャンテンプレートの上書き

ジョブ定義をオーバーライドする場合（例えば、variables のようなプロパティを変更する場合）、テンプレートをインクルードした後にジョブを宣言してオーバーライドし、追加のキーを指定する必要があります。

この例では、GIT_STRATEGY をfetch に設定しています：

include:
  - template: Security/Container-Scanning.gitlab-ci.yml

container_scanning:
  variables:
    GIT_STRATEGY: fetch

スキャナの変更

コンテナ・スキャンニング・アナライザーは、設定変数CS_ANALYZER_IMAGE の値によって、異なるスキャナーを使用することができます。

以下のオプションが利用できます：

デフォルトブランチイメージの設定

GitLab 14.5 で導入されました。

デフォルトでは、コンテナスキャンはイメージの命名規則がイメージ名ではなくイメージタグにブランチ固有の識別子を保存していると仮定します。イメージ名がデフォルトブランチと非デフォルトブランチで異なる場合、以前に検出された脆弱性がマージリクエストで新たに検出されたものとして表示されます。

同じイメージがデフォルトブランチと非デフォルトブランチで異なる名前を持っている場合、CS_DEFAULT_BRANCH_IMAGE 変数を使用して、そのイメージのデフォルトブランチでの名前を示すことができます。そうすることで、GitLab はデフォルトブランチ以外でスキャンを実行する際に、脆弱性が既に存在するかどうかを正しく判断します。

例として、次のようにします：

• デフォルトでないブランチは、$CI_REGISTRY_IMAGE/$CI_COMMIT_BRANCH:$CI_COMMIT_SHA という命名規則で画像を公開しています。
• デフォルトブランチでは、$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA という命名規則で画像を公開しています。

この例では、以下の CI/CD 設定を使うことで、脆弱性が重複しないようにすることができます：

include:
  - template: Security/Container-Scanning.gitlab-ci.yml

container_scanning:
  variables:
    CS_DEFAULT_BRANCH_IMAGE: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
  before_script:
    - export CS_IMAGE="$CI_REGISTRY_IMAGE/$CI_COMMIT_BRANCH:$CI_COMMIT_SHA"
    - |
      if [ "$CI_COMMIT_BRANCH" == "$CI_DEFAULT_BRANCH" ]; then
        export CS_IMAGE="$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA"
      fi

CS_DEFAULT_BRANCH_IMAGE は、与えられたCS_IMAGE に対して同じであるべきです。もし変更された場合、脆弱性の重複したセットが作成され、手動で削除しなければなりません。

Auto DevOps を使用する場合、CS_DEFAULT_BRANCH_IMAGE は自動的に$CI_REGISTRY_IMAGE/$CI_DEFAULT_BRANCH:$CI_APPLICATION_TAG に設定されます。

カスタムSSL CA認証局の使用

ADDITIONAL_CA_CERT_BUNDLE CI/CD変数を使用して、カスタムSSL CA認証局を設定することができます。この認証局は、HTTPSを使用するレジストリからDockerイメージを取得する際に、ピアの検証に使用さ ADDITIONAL_CA_CERT_BUNDLEれます。ADDITIONAL_CA_CERT_BUNDLE この ADDITIONAL_CA_CERT_BUNDLE値には、X.509 PEM公開鍵証明書のテキスト表現を含める必要があります。例えば、.gitlab-ci.yml ファイルでこの値を設定するには、以下を使用します：

container_scanning:
  variables:
    ADDITIONAL_CA_CERT_BUNDLE: |
        -----BEGIN CERTIFICATE-----
        MIIGqTCCBJGgAwIBAgIQI7AVxxVwg2kch4d56XNdDjANBgkqhkiG9w0BAQsFADCB
        ...
        jWgmPqF3vUbZE0EyScetPJquRFRKIesyJuBFMAs=
        -----END CERTIFICATE-----

ADDITIONAL_CA_CERT_BUNDLE 値は、UI のカスタム変数として設定することもできます。file として設定する場合は証明書へのパスが必要で、変数として設定する場合は証明書のテキスト表現が必要です。

脆弱性許可リスト

特定の脆弱性を許可リストに登録するには、以下の手順に従います：

1. コンテナ・スキャン・テンプレートのオーバーライドの説明に従って、.gitlab-ci.yml ファイルにGIT_STRATEGY: fetch を設定します。
2. vulnerability-allowlist.yml という名前の YAML ファイルに allowlisted 脆弱性を定義します。これは、vulnerability-allowlist.yml データ形式で説明されている形式を使用する必要があります。
3. vulnerability-allowlist.yml ファイルをプロジェクトの Git リポジトリのルートフォルダに追加してください。

vulnerability-allowlist.yml データ形式

vulnerability-allowlist.yml ファイルは YAML ファイルで、存在してもよい脆弱性の CVE ID のリストを指定します。これは_誤検出_であるか、あるいは_該当_しないためです。

vulnerability-allowlist.yml ファイルにマッチするエントリが見つかると、次のようになります：

• アナライザがgl-container-scanning-report.json ファイルを生成する際、脆弱性は内部に含まれません。
• パイプラインの[セキュリティ]タブには脆弱性は表示されません。セキュリティ] タブの真実のソースである JSON ファイルには含まれていません。

vulnerability-allowlist.yml ファイルの例：

generalallowlist:
  CVE-2019-8696:
  CVE-2014-8166: cups
  CVE-2017-18248:
images:
  registry.gitlab.com/gitlab-org/security-products/dast/webgoat-8.0@sha256:
    CVE-2018-4180:
  your.private.registry:5000/centos:
    CVE-2015-1419: libxml2
    CVE-2015-1447:

この例では、gl-container-scanning-report.json を除外しています：

1. CVE ID を持つすべての脆弱性：CVE_-2019-8696、_CVE-2014-8166、CVE-2017-18248。
2. CVE ID が_CVE-2018-4180_ のregistry.gitlab.com/gitlab-org/security-products/dast/webgoat-8.0@sha256 コンテナイメージで見つかったすべての脆弱性。
3. CVE ID が_CVE-2015-1419_,_CVE-2015-1447_のyour.private.registry:5000/centos コンテナで見つかったすべての脆弱性。

ファイル形式

• generalallowlist ブロックでは、CVE ID をグローバルに指定できます。CVE ID が一致するすべての脆弱性は、スキャン レポートから除外されます。

• images ブロックでは、各コンテナイメージの CVE ID を個別に指定できます。指定されたイメージの CVE ID に一致するすべての脆弱性がスキャン レポートから除外されます。イメージ名は、スキャン対象のDockerイメージを指定するために使用される環境変数（$CI_APPLICATION_REPOSITORY:$CI_APPLICATION_TAG やCS_IMAGE など）の1つから取得されます。 このブロックで提供されるイメージは、この値と一致する必要があり、タグ値を含んではいけません。例えば、スキャンする画像をCS_IMAGE=alpine:3.7で指定した場合、images ブロックではalpine を使用しますが、alpine:3.7を使用することはできません。

  コンテナ画像は複数の方法で指定できます：

  • イメージ名のみ（centos など）。
  • レジストリホスト名を含む完全なイメージ名として (your.private.registry:5000/centos など)。
  • レジストリホスト名と sha256 ラベルを含む完全なイメージ名として (registry.gitlab.com/gitlab-org/security-products/dast/webgoat-8.0@sha256 など)。

コンテナスキャンジョブのログ形式

container_scanning ジョブの詳細でコンテナスキャンアナライザが生成するログを見ることで、スキャンの結果とvulnerability-allowlist.yml ファイルの正しさを確認できます。

ログには、発見された脆弱性のリストが表として含まれています：

+------------+-------------------------+------------------------+-----------------------+------------------------------------------------------------------------+
|   STATUS   |      CVE SEVERITY       |      PACKAGE NAME      |    PACKAGE VERSION    |                            CVE DESCRIPTION                             |
+------------+-------------------------+------------------------+-----------------------+------------------------------------------------------------------------+
|  Approved  |   High CVE-2019-3462    |          apt           |         1.4.8         | Incorrect sanitation of the 302 redirect field in HTTP transport metho |
|            |                         |                        |                       | d of apt versions 1.4.8 and earlier can lead to content injection by a |
|            |                         |                        |                       |  MITM attacker, potentially leading to remote code execution on the ta |
|            |                         |                        |                       |                             rget machine.                              |
+------------+-------------------------+------------------------+-----------------------+------------------------------------------------------------------------+
| Unapproved |  Medium CVE-2020-27350  |          apt           |         1.4.8         | APT had several integer overflows and underflows while parsing .deb pa |
|            |                         |                        |                       | ckages, aka GHSL-2020-168 GHSL-2020-169, in files apt-pkg/contrib/extr |
|            |                         |                        |                       | acttar.cc, apt-pkg/deb/debfile.cc, and apt-pkg/contrib/arfile.cc. This |
|            |                         |                        |                       |  issue affects: apt 1.2.32ubuntu0 versions prior to 1.2.32ubuntu0.2; 1 |
|            |                         |                        |                       | .6.12ubuntu0 versions prior to 1.6.12ubuntu0.2; 2.0.2ubuntu0 versions  |
|            |                         |                        |                       | prior to 2.0.2ubuntu0.2; 2.1.10ubuntu0 versions prior to 2.1.10ubuntu0 |
|            |                         |                        |                       |                                  .1;                                   |
+------------+-------------------------+------------------------+-----------------------+------------------------------------------------------------------------+
| Unapproved |  Medium CVE-2020-3810   |          apt           |         1.4.8         | Missing input validation in the ar/tar implementations of APT before v |
|            |                         |                        |                       | ersion 2.1.2 could result in denial of service when processing special |
|            |                         |                        |                       |                         ly crafted deb files.                          |
+------------+-------------------------+------------------------+-----------------------+------------------------------------------------------------------------+

対応する CVE ID がvulnerability-allowlist.yml ファイルに追加されると、ログ中の脆弱性はApproved としてマークされます。

オフライン環境でのコンテナスキャンの実行

インターネットを通じた外部リソースへのアクセスが制限されている、制限されている、または断続的な環境にある自己管理GitLabインスタンスでは、コンテナスキャンジョブを正常に実行するためにいくつかの調整が必要です。詳細については、オフライン環境を参照してください。

オフライン・コンテナ・スキャンの要件

オフライン環境でコンテナスキャンを使用するには、以下が必要です：

• GitLab Runner with thedocker orkubernetes executor.
• コンテナスキャンイメージのコピーをローカルDockerコンテナレジストリに設定するには。これらのイメージは、それぞれのレジストリで見つけることができます：

GitLab Runnerのデフォルトのpull policy はalways、つまりランナーはGitLabコンテナレジストリからDockerイメージを引き出そうとします、たとえ内部コピーが利用可能であっても。ローカルで利用可能なDockerイメージのみを使用したい場合は、オフライン環境でGitLab Runnerpull_policy をif-not-present に設定することができます。しかし、オフライン環境でない場合は、CI/CDパイプラインで更新されたスキャナを使用できるようにするため、プルポリシー設定をalways に保つことをお勧めします。

カスタム認証局のサポート

カスタム認証局のサポートは以下のバージョンで導入されました：

GitLabコンテナスキャンアナライザーイメージをDockerレジストリ内で利用可能にします。

コンテナスキャンを行うには、registry.gitlab.com から以下のイメージをローカルの Docker コンテナレジストリにインポートします：

registry.gitlab.com/security-products/container-scanning:6
registry.gitlab.com/security-products/container-scanning/grype:6
registry.gitlab.com/security-products/container-scanning/trivy:6

DockerイメージをローカルのオフラインDockerレジストリにインポートするプロセスは、ネットワークセキュリティポリシーによって異なります。外部リソースをインポートしたり、一時的にアクセスしたりするための承認者プロセスを見つけるには、IT担当者に相談してください。これらのスキャナは定期的に更新されるため、時折自分で更新することができるかもしれません。

詳細については、パイプラインを使用して画像を更新する方法の具体的な手順を参照してください。

Dockerイメージをファイルとして保存して転送する方法の詳細については、docker save、docker load、docker export、docker importのDockerドキュメントを参照してください。

ローカルコンテナスキャナアナライザを使用するためのコンテナスキャンCI/CD変数の設定

1. .gitlab-ci.yml ファイルのコンテナスキャンテンプレートをオーバーライドして、ローカルのDockerコンテナレジストリでホストされているDockerイメージを参照するようにします：

   include:
     - template: Security/Container-Scanning.gitlab-ci.yml
      
   container_scanning:
     image: $CI_REGISTRY/namespace/container-scanning
   

2. ローカルのDockerコンテナレジストリがHTTPS を介して安全に実行されているが、自己署名証明書を使用している場合は、.gitlab-ci.ymlの上記のcontainer_scanning セクションでCS_DOCKER_INSECURE: "true" を設定する必要があります。

パイプラインによるコンテナスキャン脆弱性データベース更新の自動化

事前に設定したスケジュールで最新の脆弱性データベースを取得するよう、スケジュールされたパイプラインを設定することをお勧めします。パイプラインでこれを自動化すると、毎回手動で行う必要がなくなります。以下の.gitlab-ci.yml の例をテンプレートとして使用できます。

variables:
  SOURCE_IMAGE: registry.gitlab.com/security-products/container-scanning:6
  TARGET_IMAGE: $CI_REGISTRY/namespace/container-scanning

image: docker:latest

update-scanner-image:
  services:
    - docker:dind
  script:
    - 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

上記のテンプレートは、ローカルインストール上で動作するGitLab Dockerレジストリで動作します。しかし、GitLab以外のDockerレジストリを使っている場合は、$CI_REGISTRY の値とdocker login の認証情報をローカルのレジストリの詳細に合わせて変更する必要があります。

外部の非公開レジストリ内のイメージをスキャンします。

外部の非公開レジストリ内のイメージをスキャンするには、コンテナ スキャン アナライザがスキャン対象のイメージにアクセスする前に自身を認証できるように、アクセス認証情報を設定する必要があります。

GitLabコンテナレジストリを使用する場合は、CS_REGISTRY_USER とCS_REGISTRY_PASSWORD の設定変数が自動的に設定されるので、この設定は省略できます。

この例では、非公開のGoogle コンテナレジストリで画像をスキャンするために必要な設定を示します：

include:
  - template: Security/Container-Scanning.gitlab-ci.yml

container_scanning:
  variables:
    CS_REGISTRY_USER: _json_key
    CS_REGISTRY_PASSWORD: "$GCP_CREDENTIALS"
    CS_IMAGE: "gcr.io/path-to-you-registry/image:tag"

この設定をコミットする前に、Google Cloud Platform Container Registry のドキュメントに記載されているように、JSON キーを含むGCP_CREDENTIALS 用のCI/CD 変数を追加してください。また

• 変数の値がMask 変数オプションのマスキング要件に合わない可能性があるため、ジョブログで値が公開される可能性があります。
• 変数の保護] オプションを選択すると、保護されていない機能ブランチでスキャンが実行されない場合があります。
• オプションが選択されていない場合は、読み取り専用の権限を持つ資格情報を作成し、定期的にローテーションすることを検討してください。

FIPS モードが有効な場合、外部非公開レジストリ内のイメージのスキャンはサポートされません。

スタンドアロンコンテナスキャンツールの実行

GitLabコンテナスキャンツールをDockerコンテナに対して実行することができます。イメージを直接スキャンするには、以下の手順に従ってください：

1. Docker DesktopまたはDocker Machineを起動します。

2. アナライザのDockerイメージを実行し、CI_APPLICATION_REPOSITORY とCI_APPLICATION_TAG の変数に分析したいイメージとタグを渡します：

   docker run \
     --interactive --rm \
     --volume "$PWD":/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_TAG=bc09fe2e0721dfaeee79364115aeedf2174cce0947b9ae5fe7c33312ee019a4e \
     registry.gitlab.com/security-products/container-scanning
   

結果はgl-container-scanning-report.json に格納されます。

レポートのJSON形式

コンテナスキャンツールは、CI設定ファイルのartifacts:reports キーワードを通してGitLab Runnerが認識するJSONレポートを発行します。

CIジョブが終了すると、RunnerはこれらのレポートをGitLabにアップロードし、CIジョブのアーティファクトで利用できるようになります。GitLab Ultimateでは、これらのレポーターは対応するパイプラインで見ることができ、脆弱性レポートの一部になります。

これらのレポーターは、セキュリティレポートスキーマで定義されたフォーマットに従わなければなりません。参照してください：

• コンテナ検査レポートの最新スキーマ。
• コンテナ・スキャン・レポートの例

詳細については、セキュリティスキャナーのインテグレーションを参照してください。

CycloneDXソフトウェア部品表

GitLab 15.11 で導入。

コンテナスキャニングツールは、JSONレポートファイルに加えて、スキャンした画像のCycloneDXソフトウェア部品表(SBOM) 。このCycloneDX SBOMは、gl-sbom-report.cdx.json という名前で、JSON report fileと同じディレクトリに保存されます。この機能は、Trivy アナライザーが使用されている場合にのみサポートされます。

CycloneDX SBOMは、他のジョブのアーティファクトと同じ方法でダウンロードできます。

セキュリティダッシュボード

セキュリティダッシュボードは、グループ、プロジェクト、パイプライン内のすべてのセキュリティ脆弱性の概要を表示します。

脆弱性データベース

すべてのアナライザーイメージは毎日更新されます。

画像は、どのスキャナーを使用するかによって、アップストリーム勧告データベースのデータを使用します：

これらのスキャナが提供するソースに加えて、GitLabは以下の脆弱性データベースを管理しています：

• 独自のGitLab Advisory Database。
• オープンソースのGitLab Advisory Database（オープンソース版）。

GitLab Ultimateティアでは、GitLab Advisory Databaseのデータがマージされ、外部ソースからのデータを補強します。GitLab PremiumとFreeの階層では、GitLab Advisory Database (Open Source Edition)のデータがマージされ、外部ソースからのデータを補強します。この増強は現在、Trivyスキャナーのアナライザーイメージにのみ適用されます。

他のアナライザーのデータベース更新情報はメンテナンステーブルで入手できます。

脆弱性との対話

脆弱性が見つかったら、それにアドレスすることができます。

脆弱性の解決（自動修復）

脆弱性の中には、GitLabが自動的に生成する解決策を適用することで修正できるものがあります。

修復サポートを有効にするには、スキャンツールが CI/CD 変数CS_DOCKERFILE_PATH で指定されたDockerfile にアクセスできる_必要があります_。スキャンツールがこのファイルにアクセスできるようにするには、このドキュメントのコンテナスキャンテンプレートの上書きセクションで説明されている手順に従って、.gitlab-ci.yml ファイルにGIT_STRATEGY: fetch を設定する必要があります。

脆弱性の解決策についてもっと読んでください。

トラブルシューティング

docker: Error response from daemon: failed to copy xattrs

Runner がdocker Executor を使用し、NFS が使用されている場合（例えば、/var/lib/docker が NFS マウント上にある場合）、コンテナスキャンが次のようなエラーで失敗することがあります：

docker: Error response from daemon: failed to copy xattrs: failed to set xattr "security.selinux" on /path/to/file: operation not supported.

これはDockerのバグによるもので、現在は修正されていますfs。このエラーを防ぐには、Runnerが使用しているDockerのバージョンが18.09.03 以上であることを確認してください。詳細については、イシュー #10241を参照してください。

警告メッセージgl-container-scanning-report.json: no matching files

これについては、一般的なアプリケーションセキュリティのトラブルシューティングのセクションを参照してください。

変更点

コンテナスキャンアナライザーの変更点はプロジェクトの変更履歴にあります。