コンテナの脆弱性は、次のデプロイメントを待ってくれるわけではありません。イメージのビルド時や、コンテナが本番環境で稼働している間など、あらゆるタイミングで発生する可能性があります。 GitLab はこうした現実に対応するため、コンテナライフサイクルのさまざまな段階に対応した複数のコンテナスキャンアプローチを提供しています。
本ガイドでは、GitLab が提供するコンテナスキャンの種類、各機能の有効化方法、および初期設定に役立つ一般的な構成についてご説明します。
コンテナスキャンが重要な理由
コンテナイメージのセキュリティ脆弱性は、アプリケーションライフサイクル全体にわたってリスクをもたらします。ベースイメージ、OSパッケージ、アプリケーションの依存関係はいずれも、攻撃者が積極的に悪用する脆弱性を含んでいる可能性があります。コンテナスキャンはこれらのリスクを早期に、本番環境に到達する前に検出し、利用可能な場合は修正方法を提供します。
コンテナスキャンはソフトウェアコンポジション分析（SCA）の重要なコンポーネントであり、コンテナ化されたアプリケーションが依存する外部依存関係を把握し、保護するために役立ちます。
GitLab コンテナスキャンの5つの種類
GitLab は5つの異なるコンテナスキャンアプローチを提供しており、それぞれがセキュリティ戦略において固有の目的を果たします。
1. パイプラインベースのコンテナスキャン
- 機能：CI/CDパイプラインの実行中にコンテナイメージをスキャンし、デプロイ前に脆弱性を検出します。
- 最適な用途：シフトレフトセキュリティ、脆弱性のあるイメージが本番環境に到達するのを防止
- 利用可能なプラン：Free、Premium、Ultimate（Ultimateではより高度な機能を利用可能）
- ドキュメント
GitLab は Trivy セキュリティスキャナーを使用してコンテナイメージの既知の脆弱性を分析します。パイプラインの実行時にスキャナーがイメージを検査し、詳細なレポートを生成します。
パイプラインベースのコンテナスキャンを有効にする方法
オプション A：事前設定済みのマージリクエスト
- プロジェクトで Secure > セキュリティ設定 に移動します。
- 「コンテナスキャン」の行を見つけます。
- マージリクエストで設定 を選択します。
- 必要な設定を含むマージリクエストが自動的に作成されます。
オプション B：手動設定
.gitlab-ci.ymlに以下を追加します。
include:
- template: Jobs/Container-Scanning.gitlab-ci.yml
一般的な設定
特定のイメージをスキャンする：
特定のイメージをスキャンするには、container_scanning ジョブの CS_IMAGE 変数を上書きします。
include:
- template: Jobs/Container-Scanning.gitlab-ci.yml
container_scanning:
variables:
CS_IMAGE: myregistry.com/myapp:latest
重大度のしきい値でフィルタリングする：
特定の重大度基準を持つ脆弱性のみを検出するには、container_scanning ジョブの CS_SEVERITY_THRESHOLD 変数を上書きします。以下の例では、重大度が High 以上の脆弱性のみが表示されます。
include:
- template: Jobs/Container-Scanning.gitlab-ci.yml
container_scanning:
variables:
CS_SEVERITY_THRESHOLD: "HIGH"
マージリクエストでの脆弱性の確認
マージリクエスト内でコンテナスキャンの脆弱性を直接確認することで、セキュリティレビューをシームレスかつ効率的に実施できます。CI/CDパイプラインにコンテナスキャンを設定すると、GitLab はマージリクエストのセキュリティウィジェットに検出された脆弱性を自動的に表示します。
マージリクエストに表示されたコンテナスキャンの脆弱性
- マージリクエストの「セキュリティスキャン」セクションまでスクロールすると、コンテナイメージで新たに検出された脆弱性と既存の脆弱性の概要が確認できます。
- 脆弱性 をクリックすると、重大度レベル、影響を受けるパッケージ、利用可能な修正ガイダンスなど、検出内容の詳細情報にアクセスできます。
MRでのコンテナスキャン脆弱性の詳細
この可視性により、開発者とセキュリティチームはコンテナの脆弱性が本番環境に到達する前に発見・対処できるようになり、セキュリティがコードレビュープロセスに統合されます。
脆弱性レポートでの脆弱性の確認
マージリクエストのレビューに加え、GitLab はプロジェクト内のすべてのコンテナスキャン結果を一元的に確認できる脆弱性レポートを提供しており、セキュリティチームに包括的な可視性をもたらします。
コンテナスキャンでフィルタリングされた脆弱性レポート
- プロジェクトのサイドバーで セキュリティとコンプライアンス > 脆弱性レポート に移動してレポートにアクセスします。
- ここでは、ブランチ全体で検出されたすべてのコンテナ脆弱性が集約されて表示され、重大度、ステータス、スキャナーの種類、特定のコンテナイメージでフィルタリングする強力なオプションが利用できます。
- 脆弱性をクリックすると、脆弱性ページにアクセスできます。
コンテナスキャン脆弱性の詳細
脆弱性の詳細では、影響を受けるコンテナイメージとレイヤーが正確に示されるため、脆弱性の発生源を容易に追跡できます。脆弱性をチームメンバーに割り当て、ステータスを変更（検出済み、確認済み、解決済み、却下済み）し、コラボレーションのためのコメントを追加し、修正作業の追跡のために関連するイシューをリンクすることができます。
このワークフローにより、脆弱性管理がスプレッドシートによる管理から開発プロセスの一部へと変わり、コンテナセキュリティの検出結果が体系的に追跡・優先順位付け・解決されるようになります。
依存関係リストの確認
GitLab の依存関係リストは、コンテナイメージ内のすべてのコンポーネントをカタログ化した包括的なソフトウェア部品表（SBOM）を提供し、ソフトウェアサプライチェーンの完全な透明性をもたらします。
- セキュリティとコンプライアンス > 依存関係リスト に移動すると、プロジェクト全体でコンテナスキャンが検出したすべてのパッケージ、ライブラリ、依存関係のインベントリにアクセスできます。
- このビューは、ベースOSパッケージからアプリケーションレベルの依存関係まで、コンテナ内で実際に稼働しているものを把握するために非常に役立ちます。
GitLab 依存関係リスト（SBOM）
パッケージマネージャー、ライセンスの種類、または脆弱性のステータスでリストをフィルタリングすることで、セキュリティリスクやコンプライアンス上の問題をもたらすコンポーネントを素早く特定できます。各依存関係エントリには関連する脆弱性が表示されるため、単独の検出結果としてではなく、実際のソフトウェアコンポーネントのコンテキストでセキュリティの問題を把握できます。
2. レジストリ向けコンテナスキャン
- 機能：
latestタグで GitLab コンテナレジストリにプッシュされたイメージを自動的にスキャンします。 - 最適な用途：手動のパイプラインを実行することなく、レジストリイメージの継続的なモニタリングを実施
- 利用可能なプラン：Ultimate のみ
- ドキュメント
latest タグが付いたコンテナイメージをプッシュすると、GitLab のセキュリティポリシーボットがデフォルトブランチに対してスキャンを自動的にトリガーします。パイプラインベースのスキャンとは異なり、このアプローチは継続的脆弱性スキャンと連携して、新たに公開されたアドバイザリーを監視します。
レジストリ向けコンテナスキャンを有効にする方法
- Secure > セキュリティ設定 に移動します。
- レジストリ向けコンテナスキャン セクションまでスクロールします。
- 機能をオンに切り替えます。
レジストリ向けコンテナスキャンの切り替えスイッチ
前提条件
- プロジェクトのメンテナーロール以上
- プロジェクトが空でないこと（デフォルトブランチに少なくとも1つのコミットが必要）
- コンテナレジストリの通知が設定済みであること
- パッケージメタデータデータベースが設定済みであること（GitLab.com ではデフォルトで有効）
脆弱性は脆弱性レポートの コンテナレジストリの脆弱性 タブに表示されます。
3. マルチコンテナスキャン
- 機能：単一のパイプライン内で複数のコンテナイメージを並行してスキャンします。
- 最適な用途：マイクロサービスアーキテクチャや複数のコンテナイメージを持つプロジェクト
- 利用可能なプラン：Free、Premium、Ultimate（現在ベータ版）
- ドキュメント
マルチコンテナスキャンは動的な子パイプラインを使用してスキャンを並行実行するため、複数のイメージをスキャンする際のパイプライン全体の実行時間を大幅に短縮できます。
マルチコンテナスキャンを有効にする方法
- リポジトリのルートに
.gitlab-multi-image.ymlファイルを作成します。
scanTargets:
- name: alpine
tag: "3.19"
- name: python
tag: "3.9-slim"
- name: nginx
tag: "1.25"
.gitlab-ci.ymlにテンプレートを追加します。
include:
- template: Jobs/Multi-Container-Scanning.latest.gitlab-ci.yml
詳細設定
プライベートレジストリからイメージをスキャンする：
auths:
registry.gitlab.com:
username: ${CI_REGISTRY_USER}
password: ${CI_REGISTRY_PASSWORD}
scanTargets:
- name: registry.gitlab.com/private/image
tag: latest
ライセンス情報を含める：
includeLicenses: true
scanTargets:
- name: postgres
tag: "15-alpine"
4. 継続的脆弱性スキャン
- 機能：パイプラインを実行することなく、新しいセキュリティアドバイザリーが公開された際に自動的に脆弱性を作成します。
- 最適な用途：デプロイ間のプロアクティブなセキュリティモニタリング
- 利用可能なプラン：Ultimate のみ
- ドキュメント
従来のスキャンは、スキャン実行時の脆弱性しか検出できません。しかし、昨日スキャンしたパッケージに対して、明日新しい CVE が公開された場合はどうなるでしょうか。継続的脆弱性スキャンは、GitLab アドバイザリーデータベースを監視し、新しいアドバイザリーがコンポーネントに影響を与える際に自動的に脆弱性レコードを作成することでこの課題を解決します。
仕組み
- コンテナスキャンまたは依存関係スキャンジョブが CycloneDX SBOM を生成します。
- GitLab はこの SBOM からプロジェクトのコンポーネントを登録します。
- 新しいアドバイザリーが公開されると、GitLab はコンポーネントが影響を受けるかどうかを確認します。
- 脆弱性レポートに脆弱性が自動的に作成されます。
重要な考慮事項
- スキャンは CI パイプラインではなく、バックグラウンドジョブ（Sidekiq）経由で実行されます。
- 新しいコンポーネント検出には、過去14日以内に公開されたアドバイザリーのみが対象となります。
- 脆弱性では「GitLab SBoM Vulnerability Scanner」がスキャナー名として使用されます。
- 脆弱性を解決済みとしてマークするには、引き続きパイプラインベースのスキャンを実行する必要があります。
5. 運用コンテナスキャン
- 機能：スケジュールされた間隔で Kubernetes クラスター内の稼働中のコンテナをスキャンします。
- 最適な用途：デプロイ後のセキュリティモニタリングとランタイム脆弱性の検出
- 利用可能なプラン：Ultimate のみ
- ドキュメント
運用コンテナスキャンは、ビルド時のセキュリティとランタイムセキュリティの間のギャップを埋めます。GitLab Agent for Kubernetes を使用して、クラスター内で実際に稼働しているコンテナをスキャンし、デプロイ後に発生する脆弱性を検出します。
運用コンテナスキャンを有効にする方法
GitLab Kubernetes Agent を使用している場合、エージェント設定ファイルに以下を追加できます。
container_scanning:
cadence: '0 0 * * *' # 毎日深夜0時
vulnerability_report:
namespaces:
include:
- production
- staging
また、GitLab Kubernetes Agent によるスケジュールスキャンを強制するスキャン実行ポリシーを作成することもできます。
運用コンテナスキャンのスキャン実行ポリシー条件
結果の確認
- 運用 > Kubernetes クラスター に移動します。
- エージェント タブを選択し、エージェントを選択します。
- セキュリティ タブを選択してクラスターの脆弱性を確認します。
- 結果は 脆弱性レポート の 運用上の脆弱性 タブにも表示されます。
GitLab セキュリティポリシーによるセキュリティ態勢の強化
GitLab セキュリティポリシーを使用すると、自動化されたポリシー駆動型のコントロールを通じて、コンテナワークフロー全体で一貫したセキュリティ標準を適用できます。これらのポリシーは、要件を開発パイプラインに直接組み込むことでセキュリティをシフトレフトし、コードが本番環境に到達する前に脆弱性を検出・対処できるようにします。
スキャン実行ポリシーとパイプラインポリシー
スキャン実行ポリシーは、プロジェクト全体でコンテナスキャンがいつ・どのように実行されるかを自動化します。すべてのマージリクエストでコンテナスキャンをトリガーし、メインブランチの定期的なスキャンをスケジュールするポリシーなどを定義できます。これらのポリシーにより、各プロジェクトの CI/CD パイプラインで手動でスキャンを設定することなく、包括的なカバレッジが確保されます。
使用するスキャナーのバージョンを指定し、スキャンパラメーターを一元的に設定することで、新しいコンテナセキュリティの脅威に対応しながら組織全体の一貫性を維持できます。
スキャン実行ポリシーの設定
パイプライン実行ポリシーは、コンプライアンス要件に基づいてパイプラインにカスタムジョブを注入（または上書き）するための柔軟なコントロールを提供します。
これらのポリシーを使用して、コンテナスキャンジョブをパイプラインに自動的に注入したり、コンテナの脆弱性がリスク許容度を超えた場合にビルドを失敗させたり、特定のブランチやタグに対して追加のセキュリティチェックをトリガーしたり、本番環境向けコンテナイメージのコンプライアンス要件を適用したりすることができます。パイプライン実行ポリシーは自動化されたガードレールとして機能し、手動操作なしですべてのコンテナデプロイメントにセキュリティ標準が一貫して適用されるようにします。
パイプライン実行ポリシーのアクション
マージリクエスト承認ポリシー
マージリクエスト承認ポリシーは、コンテナの脆弱性を含むマージリクエストを指定された承認者がレビューし、承認することを要求することでセキュリティゲートを適用します。
重大度の高い脆弱性が検出された場合にマージをブロックするポリシーや、新しいコンテナの検出結果を導入するマージリクエストにセキュリティチームの承認を要求するポリシーを設定できます。これらのポリシーにより、低リスクな変更の開発速度を維持しながら、脆弱性のあるコンテナイメージがパイプラインを通じて進むことを防ぎます。
MRでブロックを実行するマージリクエスト承認ポリシー
適切なアプローチの選択
| スキャンの種類 | 使用するタイミング | 主なメリット |
|---|---|---|
| パイプラインベース | すべてのビルド時 | シフトレフトセキュリティ、脆弱なビルドをブロック |
| レジストリスキャン | 継続的なモニタリング | 保存されたイメージの新しい CVE を検出 |
| マルチコンテナ | マイクロサービス | 並行スキャン、パイプラインの高速化 |
| 継続的脆弱性 | デプロイ間 | プロアクティブなアドバイザリーモニタリング |
| 運用 | 本番環境のモニタリング | ランタイム脆弱性の検出 |
包括的なセキュリティのためには、複数のアプローチを組み合わせることをお勧めします。開発中の問題を検出するためのパイプラインベースのスキャン、継続的なモニタリングのためのレジストリ向けコンテナスキャン、そして本番環境の可視性のための運用スキャンを組み合わせてご活用ください。
今すぐ始める
コンテナセキュリティへの最短ルートは、パイプラインベースのスキャンを有効にすることです。
- プロジェクトの Secure > セキュリティ設定 に移動します。
- コンテナスキャンの マージリクエストで設定 をクリックします。
- 作成されたマージリクエストをマージします。
- 次のパイプラインに脆弱性スキャンが含まれるようになります。
その後、セキュリティ要件と GitLab のプランに応じて、追加のスキャンの種類を段階的に導入してください。
コンテナセキュリティは一度実施すれば完了するものではなく、継続的なプロセスです。 GitLab の包括的なコンテナスキャン機能を活用することで、ビルドからランタイムまでコンテナライフサイクルのあらゆる段階で脆弱性を検出できます。
GitLab がセキュリティ態勢の強化にどのように役立つかについての詳細は、GitLab セキュリティ & ガバナンス ソリューションページをご覧ください。
