コンテナスキャン

コンテナイメージのセキュリティの脆弱性は、アプリケーションライフサイクル全体にリスクをもたらします。コンテナスキャンは、本番環境に到達する前に、これらのリスクを早期に検出します。ベースイメージまたはオペレーティングシステムのパッケージに脆弱性がある場合、コンテナスキャンはそれらを特定し、可能な場合は修正パスを提供します。

• 概要については、Container scanning - Advanced Security Testingをご覧ください。
• チュートリアルビデオについては、How to set up container scanning using GitLabをご覧ください。
• 入門チュートリアルについては、Dockerコンテナの脆弱性をスキャンするを参照してください。

コンテナスキャンは、ソフトウェアコンポジション解析（SCA）の一部と見なされることがよくあります。SCAには、コードで使用するアイテムの検査の側面が含まれる場合があります。これらのアイテムには通常、アプリケーションやシステムの依存関係が含まれており、ほとんどの場合、これらはユーザーが記述したアイテムからではなく外部ソースからインポートされます。

GitLabは、これらのすべての依存タイプを確実に網羅するために、コンテナスキャンと依存関係スキャンの両方を提供しています。リスク領域をできるだけ広くカバーするために、すべてのセキュリティスキャナーを使用することをおすすめします。これらの機能の比較については、依存関係スキャンとコンテナスキャンの比較を参照してください。

GitLabは、Trivyセキュリティスキャナーと統合して、コンテナ内の脆弱性の静的な解析を実行します。

機能

はじめに

CI/CDパイプラインでコンテナスキャンアナライザーを有効にします。パイプラインが実行されると、アプリケーションが依存するイメージの脆弱性がスキャンされます。CI/CD変数を使用してコンテナスキャンをカスタマイズできます。

前提要件:

• .gitlab-ci.ymlファイルにはTestステージが必要です。
• Self-Managed Runnerでは、Linux/amd64上でdockerまたはkubernetes executorを備えたGitLab Runnerが必要です。GitLab.comのインスタンスRunnerを使用している場合、これはデフォルトで有効になっています。
• サポートされているディストリビューションに一致するイメージ。
• プロジェクトのコンテナレジストリに対して、Dockerイメージをビルドしてプッシュしていること。
• サードパーティのコンテナレジストリを使用している場合は、CS_REGISTRY_USERおよびCS_REGISTRY_PASSWORDのCI/CD変数を使用して認証情報を提供することが必要になる場合があります。これらの変数の使用方法の詳細については、リモートレジストリに対して認証するを参照してください。

ユーザーおよびプロジェクト固有の要件については、以下の詳細を参照してください。

アナライザーを有効にするには、次のいずれかの方法を使用します:

• Auto DevOpsを有効にします。これには、依存関係スキャンが含まれます。
• 事前設定されたマージリクエストを使用します。
• コンテナスキャンを強制するスキャン実行ポリシーを作成します。
• .gitlab-ci.ymlファイルを手動で編集します。

事前設定されたマージリクエストを使用する

この方法では、.gitlab-ci.ymlファイルにコンテナスキャンテンプレートを含むマージリクエストが自動的に準備されます。そのマージリクエストをマージすると、依存関係スキャンが有効になります。

コンテナスキャンを有効にするには:

1. 左側のサイドバーで、検索または移動先を選択して、プロジェクトを見つけます。新しいナビゲーションをオンにしている場合、このフィールドは上部のバーにあります。
2. セキュリティ > セキュリティ設定を選択します。
3. コンテナのスキャン行で、マージリクエスト経由で設定を選択します。
4. マージリクエストを作成を選択します。
5. マージリクエストをレビューして、マージを選択します。

これで、パイプラインにコンテナスキャンジョブが含まれるようになります。

.gitlab-ci.ymlファイルを手動で編集する

この方法では、既存の.gitlab-ci.ymlファイルを手動で編集する必要があります。複雑なGitLabの設定ファイルがある場合、またはデフォルト以外のオプションを使用する必要がある場合は、このメソッドを使用します。

コンテナスキャンを有効にするには:

1. 左側のサイドバーで、検索または移動先を選択して、プロジェクトを見つけます。新しいナビゲーションをオンにしている場合、このフィールドは上部のバーにあります。

2. ビルド > パイプラインエディタを選択します。

3. .gitlab-ci.ymlファイルが存在しない場合は、パイプラインの設定を選択し、例のコンテンツを削除します。

4. 次の内容をコピーして、.gitlab-ci.ymlファイルの末尾に貼り付けます。include行がすでに存在する場合は、その下にtemplate行のみを追加します。

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

5. 検証タブを選択し、パイプラインの検証を選択します。

   シミュレーションが正常に完了しましたというメッセージは、ファイルが有効であることを裏付けています。

6. 編集タブを選択します。

7. フィールドに入力します。ブランチフィールドにデフォルトブランチを使用しないでください。

8. Start a new merge request with these changes（これらの変更で新しいマージリクエストを開始）チェックボックスをオンにし、変更をコミットするを選択します。

9. 標準のワークフローに従ってフィールドに入力し、マージリクエストを作成を選択します。

10. 標準のワークフローに従ってマージリクエストをレビューおよび編集し、パイプラインが成功するまで待ってからマージを選択します。

これで、パイプラインにコンテナスキャンジョブが含まれるようになります。

結果について理解する

パイプラインの脆弱性を確認できます:

1. 左側のサイドバーで、検索または移動先を選択して、プロジェクトを見つけます。新しいナビゲーションをオンにしている場合、このフィールドは上部のバーにあります。
2. 左側のサイドバーで、ビルド > パイプラインを選択します。
3. パイプラインを選択します。
4. セキュリティタブを選択します。
5. 脆弱性を選択して、次の詳細を表示します:
   • 説明: 脆弱性の原因、潜在的な影響、推奨される修正手順について説明しています。
   • ステータス: 脆弱性がトリアージされたか、解決されたかを示します。
   • 重大度: 影響に基づいて6つのレベルに分類されます。重大度レベルの詳細はこちらをご覧ください。
   • CVSSスコア: 重大度にマップする数値を指定します。
   • EPSS: 脆弱性が実際に悪用される可能性を示します。
   • 既知の悪用された脆弱性（KEV）: 特定の脆弱性がすでに悪用されていることを示します。
   • プロジェクト: 脆弱性が特定されたプロジェクトを強調表示します。
   • レポートの種類: 出力の種類を説明します。
   • スキャナー: 脆弱性を検出したアナライザーを示します。
   • イメージ: 脆弱性に紐付けられたイメージを提供します。
   • ネームスペース: 脆弱性に紐付けられたワークスペースを示します。
   • リンク: さまざまなアドバイザリーデータベースに登録されている脆弱性の証拠です。
   • 識別子: CVE識別子など、脆弱性の分類に使用される参照の一覧です。

詳細については、パイプラインセキュリティレポートを参照してください。

コンテナスキャンの結果を確認するその他の方法:

• 脆弱性レポート: デフォルトブランチで確認された脆弱性を示します。
• コンテナスキャンのレポートアーティファクト

ロールアウトする

単一のプロジェクトでコンテナスキャンの結果に確信が持てたら、その実装を他のプロジェクトに拡張できます:

• スキャン実行の強制を使用して、グループ全体にコンテナスキャン設定を適用します。
• 固有のリクエストがある場合、コンテナスキャンはオフライン環境で実行できます。

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

次のLinuxディストリビューションがサポートされています:

• Alma Linux
• Alpine Linux
• Amazon Linux
• CentOS
• CBL-Mariner
• Debian
• Distroless
• Oracle Linux
• Photon OS
• Red Hat（RHEL）
• Rocky Linux
• SUSE
• Ubuntu

FIPS対応イメージ

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

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

設定

アナライザーの動作をカスタマイズする

コンテナスキャンをカスタマイズするには、CI/CD変数を使用します。

冗長な出力を有効にする

トラブルシューティング時など、依存関係スキャンジョブの動作を詳細に確認する必要がある場合は、冗長な出力を有効にします。

次の例では、コンテナスキャンテンプレートが含まれており、冗長な出力が有効になっています。

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

variables:
    SECURE_LOG_LEVEL: 'debug'

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

プロジェクト以外のレジストリにあるイメージをスキャンするには、次の.gitlab-ci.ymlを使用します:

include:
  - template: Jobs/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: Jobs/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"
    AWS_DEFAULT_REGION: <region>

FIPSモードが有効になっている場合、リモートレジストリに対する認証はサポートされていません。

言語固有の検出結果をレポートする

CS_DISABLE_LANGUAGE_VULNERABILITY_SCAN CI/CD変数は、スキャンでプログラミング言語に関連する検出結果をレポートするかどうかを制御します。サポートされている言語の詳細については、Trivyドキュメントの言語固有のパッケージを参照してください。

デフォルトでは、レポートにはオペレーティングシステム（OS）パッケージマネージャー（yum、apt、apk、tdnfなど）によって管理されるパッケージのみが含まれます。OS以外のパッケージのセキュリティ検出結果を報告するには、CS_DISABLE_LANGUAGE_VULNERABILITY_SCANを"false"に設定します:

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

container_scanning:
  variables:
    CS_DISABLE_LANGUAGE_VULNERABILITY_SCAN: "false"

この機能を有効にすると、プロジェクトで依存関係スキャンが有効になっている場合、脆弱性レポートに重複する検出結果が表示されることがあります。これは、GitLabが種類の異なるスキャンツール間で検出結果を自動的に重複排除できないために発生します。重複する可能性のある依存の種類の詳細については、Dependency scanning compared to container scanningを参照してください。

マージリクエストパイプラインでジョブを実行する

マージリクエストパイプラインでセキュリティスキャンツールを使用するを参照してください。

利用可能なCI/CD変数

コンテナスキャンをカスタマイズするには、CI/CD変数を使用します。次の表に、コンテナスキャンに固有のCI/CD変数を示します。定義済みCI/CD変数も使用できます。

Footnotes（脚注）:

1. 修正ステータスの情報は、ソフトウェアベンダーからの修正プログラムの提供状況に関する正確なデータと、コンテナイメージのオペレーティングシステムパッケージのメタデータに大きく依存します。また、個々のコンテナスキャナーによる解釈の影響も受けます。コンテナスキャナーが、脆弱性に対して修正されたパッケージの提供状況を誤って報告した場合、CS_IGNORE_STATUSESを使用すると、この設定が有効になっているときに検出結果のフィルタリングで誤検出や検出漏れにつながる可能性があります。

コンテナスキャンテンプレートをオーバーライドする

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

この例では、GIT_STRATEGYをfetchに設定します:

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

container_scanning:
  variables:
    GIT_STRATEGY: fetch

デフォルトブランチイメージを設定する

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

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

例として、以下を想定します:

• 非デフォルトブランチは、命名規則$CI_REGISTRY_IMAGE/$CI_COMMIT_BRANCH:$CI_COMMIT_SHAでイメージを公開します。
• デフォルトブランチは、命名規則$CI_REGISTRY_IMAGE:$CI_COMMIT_SHAでイメージを公開します。

この例では、次のCI/CD設定を使用して、脆弱性の重複を防ぐことができます:

include:
  - template: Jobs/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値には、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として、または証明書のテキスト表現を必要とする変数として、設定することもできます。

マルチアーチイメージをスキャンする

TRIVY_PLATFORM CI/CD変数を使用して、特定のオペレーティングシステムとアーキテクチャに対して実行するようにコンテナスキャンを設定できます。たとえば、.gitlab-ci.ymlファイルでこの値を設定するには、以下のように記述します:

container_scanning:
  # Use an arm64 SaaS runner to scan this natively
  tags: ["saas-linux-small-arm64"]
  variables:
    TRIVY_PLATFORM: "linux/arm64"

脆弱性の許可リスト

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

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

vulnerability-allowlist.ymlデータ形式

vulnerability-allowlist.ymlファイルは、誤検出または適用対象外であるためallowed（許可）される脆弱性のCVE IDリストを指定するYAMLファイルです。

vulnerability-allowlist.ymlファイルに一致するエントリが見つかった場合、次のようになります:

• アナライザーがgl-container-scanning-report.jsonファイルを生成する際、その脆弱性はis not included（含まれません）。
• パイプラインのセキュリティタブにその脆弱性はdoes not show（表示されません）。これは、セキュリティタブの信頼できる情報源である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. registry.gitlab.com/gitlab-org/security-products/dast/webgoat-8.0@sha256コンテナイメージで見つかった、CVE ID CVE-2018-4180を持つすべての脆弱性
3. your.private.registry:5000/centosコンテナで見つかった、CVE ID CVE-2015-1419、CVE-2015-1447を持つすべての脆弱性

ファイル形式

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

• imagesブロックを使用すると、コンテナイメージごとにCVE IDを個別に指定できます。指定されたイメージ内で一致するCVE IDを持つすべての脆弱性は、スキャンレポートから除外されます。イメージ名は、スキャン対象のDockerイメージを指定するために使用される環境変数（$CI_APPLICATION_REPOSITORY:$CI_APPLICATION_TAGやCS_IMAGEなど）のいずれかから取得されます。このブロックで指定するイメージは、この値と一致しているmust（必要があり）、タグの値を含めてはmust not（いけません）。たとえば、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としてマークされます。

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

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

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

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

• dockerまたはkubernetes executorを備えたGitLab Runner。
• コンテナスキャンイメージのコピーを含む、ローカルDockerコンテナレジストリを設定すること。これらのイメージは、それぞれのレジストリにあります:

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

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

バージョン4.0.0で、Trivyのカスタム認証局のサポートが導入されました。

Dockerレジストリ内でGitLabコンテナスキャンアナライザーイメージを利用できるようにする

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

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

DockerイメージをローカルのオフラインDockerレジストリにインポートするプロセスは、your network security policy（ネットワークのセキュリティポリシー）によって異なります。IT部門に相談して、外部リソースをインポートまたは一時的にアクセスするための承認済みプロセスを確認してください。これらのスキャナーは定期的に更新されています。また、自分で随時更新できる場合もあります。

詳細については、パイプラインでイメージを更新する方法に関する特定の手順を参照してください。

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

• docker save
• docker load
• docker export
• docker import

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

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

   include:
     - template: Jobs/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:8
  TARGET_IMAGE: $CI_REGISTRY/namespace/container-scanning

image: docker:cli

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のCI/CD変数が自動的に設定されるため、この設定を省略できます。

次の例は、プライベートGoogle Container Registryでイメージをスキャンするために必要な設定を示しています:

include:
  - template: Jobs/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コンテナレジストリドキュメントの説明に従って、JSONキーを含むGCP_CREDENTIALSのCI/CD変数を追加します。また、次の点に注意してください:

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

FIPSモードが有効になっている場合、外部プライベートレジストリ内のイメージのスキャンはサポートされません。

Trivy Javaデータベースミラーを作成および使用する

trivyスキャナーが使用され、スキャン対象のコンテナイメージでjarファイルが検出されると、trivyは追加のtrivy-java-db脆弱性データベースをダウンロードします。デフォルトでは、trivy-java-dbデータベースはghcr.io/aquasecurity/trivy-java-db:1でOCIアーティファクトとしてホストされます。このレジストリにアクセスできない場合、またはTOOMANYREQUESTSが返される場合は、trivy-java-dbをよりアクセスしやすいコンテナレジストリにミラーリングするという解決策があります:

mirror trivy java db:
  image:
    name: ghcr.io/oras-project/oras:v1.1.0
    entrypoint: [""]
  script:
    - oras login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
    - oras pull ghcr.io/aquasecurity/trivy-java-db:1
    - oras push $CI_REGISTRY_IMAGE:1 --config /dev/null:application/vnd.aquasec.trivy.config.v1+json javadb.tar.gz:application/vnd.aquasec.trivy.javadb.layer.v1.tar+gzip

脆弱性データベースは通常のDockerイメージではないため、docker pullを使用してプルすることはできません。GitLab UIでイメージに移動すると、エラーが表示されます。

コンテナレジストリがgitlab.example.com/trivy-java-db-mirrorの場合、コンテナスキャンジョブは次の方法で設定する必要があります。末尾にタグ:1を追加しないでください。このタグはtrivyによって追加されます:

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

container_scanning:
  variables:
    CS_TRIVY_JAVA_DB: gitlab.example.com/trivy-java-db-mirror

アーカイブ形式をスキャンする

コンテナスキャンは、アーカイブ形式（.tar、.tar.gz）のイメージをサポートしています。このようなイメージは、たとえば、docker saveやdocker buildx buildを使用して作成できます。

アーカイブファイルをスキャンするには、環境変数CS_IMAGEをarchive://path/to/archive形式に設定します:

• archive://スキームプレフィックスは、アナライザーにアーカイブをスキャンするよう指示します。
• path/to/archiveは、スキャン対象のアーカイブのパスを、絶対パスまたは相対パスのいずれかで指定します。

コンテナスキャンは、Docker Image Specificationに準拠したtarイメージファイルをサポートします。OCI tarballはサポートされていません。サポートされている形式の詳細については、Trivy tarファイルのサポートを参照してください。

サポートされているtarファイルをビルドする

コンテナスキャンは、イメージ名を付与するためにtarファイル内のメタデータを使用します。tarイメージファイルをビルドするときは、必ずイメージにタグを付けてください:

# Pull or build an image with a name and a tag
docker pull image:latest
# OR
docker build . -t image:latest
# Then export to tar using docker save
docker save image:latest -o image-latest.tar

# Or build an image with a tag using buildx build
docker buildx create --name container --driver=docker-container
docker buildx build -t image:latest --builder=container -o type=docker,dest=- . > image-latest.tar

# With podman
podman build -t image:latest .
podman save -o image-latest.tar image:latest

イメージ名

コンテナスキャンは、最初にアーカイブのmanifest.jsonを評価し、RepoTagsの最初の項目を使用してイメージ名を決定します。これが見つからない場合、index.jsonを使用してio.containerd.image.nameアノテーションをフェッチします。これも見つからない場合、代わりにアーカイブのファイル名を使用します。

• manifest.jsonはDocker Image Specification v1.1.0で定義されており、docker saveコマンドを使用して作成されます。
• index.json形式は、OCI Image Specification v1.1.1で定義されています。io.containerd.image.nameは、ctr image exportを使用した場合にcontainerd v1.3.0以降で使用可能です。

以前のジョブでビルドされたアーカイブをスキャンする

CI/CDジョブでビルドされたアーカイブをスキャンするには、ビルドジョブからコンテナスキャンジョブにアーカイブアーティファクトを渡す必要があります。artifacts:pathsおよびdependenciesキーワードを使用して、あるジョブから次のジョブにアーティファクトを渡します:

build_job:
  script:
    - docker build . -t image:latest
    - docker save image:latest -o image-latest.tar
  artifacts:
    paths:
      - "image-latest.tar"

container_scanning:
  variables:
    CS_IMAGE: "archive://image-latest.tar"
  dependencies:
    - build_job

プロジェクトリポジトリにあるアーカイブをスキャンする

プロジェクトリポジトリにあるアーカイブをスキャンするには、Git戦略でリポジトリへのアクセスが有効になっていることを確認してください。container_scanningジョブでGIT_STRATEGYキーワードをcloneまたはfetchのいずれかに設定します。デフォルトではnoneに設定されているためです。

container_scanning:
  variables:
    GIT_STRATEGY: fetch

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

GitLabコンテナスキャンツールをDockerコンテナに対して実行できます。CIジョブのコンテキスト内で実行する必要はありません。イメージを直接スキャンするには、次の手順に従います:

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形式のレポート

コンテナスキャンツールはJSONレポートを出力します。これは、CI/CD設定ファイルのartifacts:reportsキーワードを介してGitLab Runnerが認識します。

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

これらのレポートは、container scanning report schemaに準拠している必要があります。

コンテナスキャンレポートの例

CycloneDXソフトウェア部品表

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

このレポートは、依存関係リストで確認できます。

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

CycloneDXレポートのライセンス情報

コンテナスキャンでは、CycloneDXレポートにライセンス情報を含めることができます。この機能は、下位互換性を維持するためにデフォルトで無効になっています。

コンテナスキャンの結果でライセンススキャンを有効にするには、次のようにします:

• .gitlab-ci.ymlファイルでCS_INCLUDE_LICENSES変数を設定します:

container_scanning:
  variables:
    CS_INCLUDE_LICENSES: "true"

• この機能を有効にすると、生成されたCycloneDXレポートには、コンテナイメージで検出されたコンポーネントのライセンス情報が含まれます。

• このライセンス情報は、依存関係リストページで表示することも、ダウンロード可能なCycloneDXジョブアーティファクトの一部として表示することもできます。

SPDXライセンスのみがサポートされていることに注意してください。ただし、SPDXに準拠していないライセンスも、ユーザーにエラーを表示せずにインジェストされます。

エンドオブライフオペレーティングシステムの検出

コンテナスキャンには、コンテナイメージがエンドオブライフ（EOL）に達したオペレーティングシステムを使用している場合に、それを検出して報告する機能があります。EOLに達したオペレーティングシステムはセキュリティアップデートが提供されなくなり、新たに発見されたセキュリティ上の問題に対して脆弱な状態のままになります。

EOL検出機能は、Trivyを使用して、それぞれのディストリビューションでサポートが終了したオペレーティングシステムを特定します。EOLのオペレーティングシステムが検出されると、他のセキュリティ検出結果とともに、コンテナスキャンレポートで脆弱性として報告されます。

EOL検出を有効にするには、CS_REPORT_OS_EOLを"true"に設定します。

レジストリのコンテナスキャン

コンテナイメージがlatestタグ付きでプッシュされると、セキュリティポリシーボットによって、デフォルトブランチに対して新しいパイプラインでコンテナスキャンジョブが自動的にトリガーされます。

通常のコンテナスキャンとは異なり、スキャン結果にセキュリティレポートは含まれません。代わりに、レジストリのコンテナスキャンは、継続的脆弱性スキャンを利用して、スキャンによって検出されたコンポーネントを検査します。

セキュリティポリシーの検出結果が特定されると、GitLabはこれらの検出結果を脆弱性レポートに入力されたします。脆弱性は、脆弱性レポートページのコンテナレジストリの脆弱性タブで確認できます。

前提要件

• レジストリのコンテナスキャンを有効にするには、少なくともプロジェクトのメンテナーロールが必要です。
• 使用するプロジェクトが空であってはなりません。コンテナイメージの保存のみを目的として空のプロジェクトを利用している場合、この機能は意図したとおりに機能しません。回避策として、プロジェクトにデフォルトブランチへの最初のコミットが含まれていることを確認してください。
• デフォルトでは、1日あたり1プロジェクトにつき50回のスキャンに制限されています。
• コンテナレジストリ通知を設定する必要があります。
• Package Metadata Databaseを設定する必要があります。これはGitLab.comでデフォルトで設定されています。

レジストリのコンテナスキャンを有効にする

GitLabコンテナレジストリのコンテナスキャンを有効にするには:

1. 左側のサイドバーで、検索または移動先を選択して、プロジェクトを見つけます。新しいナビゲーションをオンにしている場合、このフィールドは上部のバーにあります。
2. セキュリティ > セキュリティ設定を選択します。
3. レジストリのコンテナのスキャンセクションまでスクロールし、切替をオンにします。

オフラインまたはインターネット未接続（エアギャップ）環境で使用する

レジストリのコンテナスキャンをオフライン環境またはインターネット未接続（エアギャップ）環境で使用するには、コンテナスキャンアナライザーイメージのローカルコピーを使用する必要があります。この機能はGitLabセキュリティポリシーボットによって管理されるため、.gitlab-ci.ymlファイルを編集してアナライザーイメージを設定することはできません。

代わりに、GitLab UIでCS_ANALYZER_IMAGE CI/CD変数を設定して、デフォルトのスキャナーイメージをオーバーライドする必要があります。動的に作成されたスキャンジョブは、UIで定義された変数を継承します。プロジェクト、グループ、またはインスタンスのCI/CD変数を使用できます。

カスタムスキャナーイメージを設定するには:

1. 左側のサイドバーで、検索または移動先を選択して、プロジェクトまたはグループを見つけます。新しいナビゲーションをオンにしている場合、このフィールドは上部のバーにあります。
2. 設定 > CI/CDを選択します。
3. 変数セクションを展開します。
4. 変数を追加するを選択し、詳細を入力します:
   • キー: CS_ANALYZER_IMAGE
   • 値: ミラーリングされたコンテナスキャンイメージの完全なURL。例: my.local.registry:5000/analyzers/container-scanning:7。
5. 変数を追加するを選択します。

これで、GitLabセキュリティポリシーボットがスキャンをトリガーする際に、指定されたイメージを使用するようになります。

脆弱性データベース

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

これらのイメージは、以下のアップストリームのアドバイザリーデータベースからのデータを使用します:

• AlmaLinux Security Advisory
• Amazon Linux Security Center
• Arch Linux Security Tracker
• SUSE CVRF
• CWE Advisories
• Debian Security Bug Tracker
• GitHub Security Advisory
• Go Vulnerability Database
• CBL-Mariner Vulnerability Data
• NVD
• OSV
• Red Hat OVAL v2
• Red Hat Security Data API
• Photon Security Advisories
• Rocky Linux UpdateInfo
• Ubuntu CVE Tracker（2021年半ば以降のデータソースのみ）

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

• 独自のGitLab Advisory Database
• オープンソースのGitLab Advisory Database（オープンソースエディション）

GitLab Ultimateプランでは、外部ソースのデータを補強するためにGitLab Advisory Databaseのデータがマージされます。GitLab PremiumおよびFreeプランでは、外部ソースのデータを補強するためにGitLab Advisory Database（オープンソースエディション）のデータがマージされます。この補強は現在、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のバグによるエラーであり、現在は修正されています。エラーを防ぐには、Runnerが使用しているDockerのバージョンが18.09.03以上であることを確認してください。詳細については、イシュー#10241を参照してください。

警告メッセージgl-container-scanning-report.json: no matching filesが表示される

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

AWS ECRのイメージをスキャンする際にunexpected status code 401 Unauthorized: Not Authorizedが表示される

このエラーは、AWSリージョンが設定されておらず、スキャナーが認証トークンを取得できない場合に発生する可能性があります。SECURE_LOG_LEVELをdebugに設定すると、次のようなログメッセージが表示されます:

[35mDEBUG[0m failed to get authorization token: MissingRegion: could not find region configuration

これを解決するには、AWS_DEFAULT_REGIONをCI/CD変数に追加します:

variables:
  AWS_DEFAULT_REGION: <AWS_REGION_FOR_ECR>

unable to open a file: open /home/gitlab/.cache/trivy/ee/db/metadata.json: no such file or directory

圧縮されたTrivyデータベースはコンテナの/tmpフォルダーに保存され、ランタイム時に/home/gitlab/.cache/trivy/{ee|ce}/dbに展開されます。このエラーは、Runner設定に/tmpディレクトリのボリュームマウントがある場合に発生する可能性があります。

これを解決するには、/tmpフォルダーをバインドする代わりに、/tmp内の特定のファイルまたはフォルダー（/tmp/myfile.txtなど）をバインドします。

context deadline exceededエラーを解決する

このエラーは、タイムアウトが発生したことを意味します。これを解決するには、十分な長さの期間を設定したTRIVY_TIMEOUT環境変数をcontainer_scanningジョブに追加します。

古いイメージに基づくイメージで脆弱性が検出されませんでした

Trivyは、更新を受信しなくなったオペレーティングシステムのイメージをスキャンしません。

これをUIに表示することは、イシュー433325で提案されています。

変更

コンテナスキャンアナライザーの変更は、プロジェクトの変更履歴で確認できます。

コンテナv6.x: 古い脆弱性データベースによるエラー

registry.gitlab.com/security-products/container-scanning/grype:6およびregistry.gitlab.com/security-products/container-scanning/grype:6-fipsアナライザーイメージを使用してコンテナスキャンを実行すると、次のような古い脆弱性データベースによるエラーが失敗する可能性があります:

1 error occurred: * the vulnerability database was built 6 days ago (max allowed age is 5 days)

このエラーは、上記のコンテナスキャンイメージのいずれかをユーザー自身のリポジトリにコピーし、その後イメージを更新しなかった場合に発生します（イメージは毎日ビルドされます）。