Skip to main content
クラウドセキュリティ

GitLab Container Scanningとは?

GitLab Container Scanningで、デプロイ前のコンテナイメージに潜む脆弱性とマルウェアを検出します。スキャンを自動化し、リスクを軽減。安全なサプライチェーンを維持し、企業のセキュリティとコンプライアンスを強化します。

著者 SentinelOne
GitLab Container Scanningとは?

GitLab Container Scanning は、コンテナ化されたアプリケーションのセキュリティと整合性を維持するために欠かせないツールです。ソフトウェアのデプロイにコンテナ化を採用する組織が増えるなか、この手法を理解し、活用する重要性はさらに高まっています。

この記事では、GitLab Container Scanning の仕組み、対応するコンテナ形式、プロジェクトへの導入に役立つベストプラクティスと実例を詳しく解説します。開発ワークフローを円滑に保ちながら、安全な開発プロセスを実現するための知識を得られます。

GitLab Container Scanning - Featured Image | SentinelOne

GitLab Container Scanningの概要

GitLabやほかのGitLab Container Scanning を理解することは、GitLabを使ってコンテナ化されたアプリケーションを保護する場合や、Dockerなどのほかの プラットフォームを使用してそれを実現しようとしている方にとって重要です。GitLab コンテナスキャンはセキュリティチェックとして機能し、ソフトウェア内の各コンポーネントを攻撃者が悪用できる脆弱性がないかチェックします。これは、その構成要素に対するアンチウイルスチェックのような役割を果たします。 プラットフォームで保護を目指す場合に重要です。GitLab Container Scanningは、ソフトウェアを構成する各コンポーネントを調べ、攻撃者に悪用されかねない脆弱性を検出します。いわば、ソフトウェアの構成要素に対するウイルス対策チェックです。

この検査では、コンテナ内のソフトウェアを詳しく調べ、問題や潜在的なリスクを検出します。現代のソフトウェア開発では欠かせない工程です。コンテナは通常、複数のソースから得た異なるコンポーネントで構成されます。アプリケーションの整合性を保つには、そのすべてがセキュリティ基準を満たす必要があります。

GitLab Container Scanningは、コンテナ化されたアプリケーションを保護するうえで重要です。脆弱性を早期に特定し、安全なシステムを維持することで、開発者と関係者の双方に安心をもたらします。

GitLab Container Scanningの仕組みとは?

GitLab Container Scanningは、コンテナイメージ内の脆弱性を自動的に特定し、解消します。脆弱性に迅速かつ確実に対処できます。その仕組みを見ていきましょう。

GitLab Container Scanningは、CI/CDパイプラインに組み込めます。スキャンを一度きりの作業ではなく、ビルドやプッシュのたびに実行する工程にできます。これにより、セキュリティチェックを開発プロセスの継続的な一部にできます。

脆弱性データベースの活用

このツールは、コンテナで使用されるソフトウェアパッケージやライブラリのコンポーネントを、既知の脆弱性データベースと照合します。これにより、コンテナ内に存在する可能性がある既知の脅威を特定できます。

レポートの生成

GitLab Container Scanningは、スキャンの完了時に包括的なレポートを生成します。検出された脆弱性とその深刻度を示し、必要に応じて修正方法や緩和策を提案します。

対応の自動化

GitLab Container Scanningでは、設定に応じて自動対応を指定できます。開発チームが対処するための課題を作成したり、重大な脆弱性が見つかった場合にCI/CDパイプライン を停止したりできます。安全でないコードの本番環境への投入を防ぎます。

修正と継続的な監視

継続的監視ツールは、コンテナの更新を継続的にスキャンし、修正作業を支えます。変更によって生じる可能性のある脆弱性を自動的にチェックし、時間の経過とともに現れる新たな脆弱性からの保護を維持します。

Callout Background Image Gradient

CNAPPマーケットガイド

このガートナーマーケットガイドのクラウドネイティブアプリケーション保護プラットフォームで、CNAPP市場の現状に関する主要な洞察を得てください。

GitLabが対応するコンテナ形式

GitLab Container Scanningが特定のコンテナ形式に対応するとは、その形式固有の構造やデータの配置を調査できるという意味です。スキャンツールのTrivyとGrypeは、さまざまなLinuxディストリビューションに幅広く対応し、異なる環境でも脆弱性を迅速に特定できます。

オープンソースのスキャンツール:

  • Trivy(コンテナとOS向けのオープンソース脆弱性スキャナー):Trivyは、コンテナとOSに特化したオープンソースの脆弱性スキャナーです。軽量ながら網羅的なスキャンで、多くのLinuxディストリビューションに存在する脆弱性を特定します。
  • Grype:Grypeは、コンテナイメージに関する正確な脆弱性データを提供します。分析ツールとしてTrivyを補完し、実際の対処に役立つ精度の高い脆弱性データを用いてセキュリティ上の脅威を詳しく調べます。

対応するLinuxディストリビューション

コンテナ形式とディストリビューションの違いを理解することが重要です。コンテナ形式はデータの格納方法を指し、ディストリビューションはLinux OSの種類を指します。GitLabのTrivyとGrypeは、幅広いディストリビューションに対応しています。主な対応状況は次のとおりです。

  • Alma Linux:Trivyでスキャン
  • Alpine Linux:GrypeとTrivyの両方に対応
  • Amazon Linux:GrypeとTrivyの両方に対応
  • BusyBox:Grypeでスキャン
  • CentOS:GrypeとTrivyの両方に対応
  • CBL-Mariner:Trivyでスキャン
  • Debian:GrypeとTrivyの両方に対応
  • Distroless:GrypeとTrivyの両方に対応
  • Oracle Linux:GrypeとTrivyの両方に対応
  • Photon OS:Trivyでスキャン
  • Red Hat (RHEL):GrypeとTrivyの両方に対応
  • Rocky Linux:Trivyでスキャン
  • SUSE:Trivyでスキャン
  • Ubuntu:GrypeとTrivyの両方に対応

幅広いディストリビューションへの対応が重要な理由

GitLab Container Scanningでは、コンテナ化されたアプリケーションが普及し、開発者がパフォーマンス、セキュリティ、互換性、個人の好みに応じて異なるLinuxディストリビューションを選ぶことが多い中、幅広いディストリビューションへの対応がますます重要になっていると認識しています。複数のディストリビューションに同時に対応することで、GitLab Container Scanningは、どの環境を選んでも開発者がアプリケーションのセキュリティを維持できるようにし、コンテナ化されたワークロードに包括的なセキュリティを提供するという当社の取り組みをさらに強化します。

GitLabでコンテナスキャンを設定する方法

GitLabでコンテナスキャンを設定すると、コンテナ化されたアプリケーションの脆弱性を自動的にスキャンできます。基本的な手順は次のとおりです。

1. 自動マージリクエストでコンテナスキャンを有効にする

GitLab 14.9では、自動マージリクエストを使ってコンテナスキャンを簡単かつ迅速に有効化できます。手順は次のとおりです。

  • 対象のプロジェクトに移動します。
  • Secure > Security Configurationに移動します。
  • Container Scanningの行で、Configure with a merge requestを選択します。

この操作により、コンテナスキャンの有効化に必要な変更を含むマージリクエストが自動生成されます。内容を確認してからマージすれば、設定は完了です。

2. .gitlab-ci.ymlファイルで設定する:

コンテナスキャンを手動で設定するには、.gitlab-ci.ymlファイルに該当するテンプレートを追加します。

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

このテンプレートは、Dockerイメージの脆弱性をスキャンし、結果をコンテナスキャンレポートのアーティファクトとして保存するcontainer_scanningジョブをCI/CDパイプラインに追加します。

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

3. コンテナスキャンの設定をカスタマイズする

GitLabでは、詳細な出力や特定のレジストリでの認証、より細かな結果の取得など、要件に合わせてコンテナスキャンを調整できます。

たとえば、詳細な出力を有効にするには、.gitlab-ci.ymlを次のように編集します。

include:   - template: Security/Container-Scanning.gitlab-ci.yml variables:     SECURE_LOG_LEVEL: 'debug'

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

次の設定を使用すると、プロジェクトのレジストリ以外にあるイメージもスキャンできます。

include:   - template: Security/Container-Scanning.gitlab-ci.yml container_scanning:   variables:     CS_IMAGE: example.com/user/image:tag

GitLabのコンテナスキャンは、自動マージリクエストでも手動でも簡単に設定できます。GitLabの強力なスキャンツールは、セキュリティチェックを開発ワークフローに組み込みます。これによりGitLabは、セキュリティを重視する現代のソフトウェア開発に欠かせない要素となります。

GitLabコンテナスキャンのベストプラクティス

1. スキャンツールを定期的に更新する

TrivyやGrypeなどのスキャンツールを最新の状態に保つことが重要です。新たな脆弱性をすばやく検出し、サポート対象のディストリビューションに加えられた変更との互換性を維持するには、定期的な更新が欠かせません。

2. 開発の早い段階でスキャンを組み込む

コンテナスキャンを開発サイクルに早く組み込むほど、脆弱性も早く特定して修正できます。GitLabのコンテナスキャンを継続的インテグレーション(CI)パイプラインに組み込めば、コードをプッシュするたびに自動でスキャンが実行されます。スキャンが開発ワークフローの一部となり、脆弱性の特定と修正を迅速化します。

3. ニーズに合わせてスキャンを調整する

すべてのプロジェクトに同じスキャンが必要なわけではありません。出力の詳細度、対象レジストリ、変数などをプロジェクトの要件に合わせて調整すると、スキャンの速度と効率が向上します。.gitlab-ci.ymlファイルのカスタマイズ機能を使い、スキャンを細かく調整してください。

4. スキャンレポートを定期的に確認し、対処する

スキャンを実行するだけでは不十分です。検出結果を確認し、速やかに対処する必要があります。コンテナスキャンのレポートを定期的に確認し、体系的に修正することで、脆弱性を迅速に特定して対処できます。既存の開発プロセスに修正ワークフローを組み込むことも有効です。

GitLabコンテナスキャンを使った脆弱性修正ワークフロー

GitLabコンテナスキャンの修正ワークフローは、コンテナイメージの脆弱性を特定し、効率的かつ体系的に解消するための複数のステップで構成されます。一般的な流れは次のとおりです。

  1. 脆弱性を特定する:GitLabのコンテナスキャン機能を使い、TrivyまたはGrypeでセキュリティスキャンを実行します。脆弱性が見つかると、その詳細をまとめたレポートが生成されます。
  2. 検出結果を分析する:コンテナスキャンのレポートを詳しく確認し、脆弱性の深刻度、種類、発生源を把握します。早急な対応が必要な問題を特定し、優先して修正します。
  3. 修正の優先順位を決める:分析結果に基づき、問題の優先順位を決めます。アプリケーションに差し迫った脅威をもたらす脆弱性を優先し、影響度や悪用の容易さも考慮します。
  4. 修正計画を立てる:優先順位を決めたら、各脆弱性に対処するための計画を立てます。必要な対策には、更新プログラムの適用、設定の変更、コードの直接修正などがあります。
  5. 修正を実施する:計画に沿って、GitLabのマージリクエストを使い、影響を受けるコード、設定、依存関係を修正します。開発者、セキュリティチーム、その他の関係者の連携が重要です。
  6. 修正結果を検証する:修正後は、新たな問題を生むことなく脆弱性に対処できたか、追加の検証を行います。コンテナイメージの再スキャンや追加テストで、脆弱性が解消され、セキュリティ上の欠陥が生じていないか確認します。
  7. 監視と継続的な改善: 修復のワークフローは一夜にして完成しません。継続的な監視、スキャン、見直しによって、その有効性を維持できます。反復的なアプローチが、長期的な有効性につながります。

実際の事例とユースケース

1. 銀行業

銀行アプリケーションでは、セキュリティが極めて重要です。従来の手法では、脆弱性を迅速に検出できないことがあります。銀行アプリのCI/CDパイプラインにGitLab Container Scanningを組み込めば、リアルタイムでの検査と修復が可能になります。セキュリティを強化するとともに、業界全体の信頼とコンプライアンスを支えます。

2. 医療

医療システムが扱う機密データは、厳格な規制に従って保護する必要があります。しかし、手作業のチェックは煩雑で、ミスも起こりがちです。医療機関はGitLab Container Scanningを脆弱性評価と継続的なコンプライアンス報告に活用できます。侵害への対策を強化しながら、報告プロセスを大幅に簡素化できます。

3. テクノロジースタートアップ

テクノロジースタートアップは、迅速な開発とセキュリティ基準の維持を両立させる必要があります。GitLab Container Scanningでコンテナ化されたアプリケーションの脆弱性を継続的にスキャンすれば、セキュリティを守りながら開発サイクルを加速できます。強固なセキュリティ態勢を維持しつつ、俊敏にイノベーションを進められます。

Callout Background Image Gradient

SentinelOneの動作を見る

SentinelOne製品のエキスパートとの1対1のデモで、AIを活用したクラウドセキュリティがどのように組織を保護できるかをご覧ください。

まとめ

GitLab Container Scanning は、現代の開発に欠かせない要素となっています。コンテナ化されたアプリケーションの脆弱性を、迅速かつ確実に検出する手段を提供します。開発パイプラインに組み込んで早期に脆弱性を可視化することで、組織は開発プロセスにセキュリティを組み込めます。リスクを軽減し、全体的なセキュリティ態勢を強化できます。

GitLab Container Scanningは、効果的なDevSecOps戦略に不可欠です。セキュリティを継続的に改善する環境を育みます。規制への準拠、顧客データの保護、俊敏な開発サイクルの維持に取り組む際も、セキュリティをイノベーションの中心に据え、業界やユースケースごとに異なるニーズに対応します。

GitLab Container Scanningに関するよくある質問

GitLab Container Scanningは、CI/CD中にコンテナイメージの脆弱性をチェックします。Trivyなどのスキャナーを使用し、ベースOSのパッケージからアプリケーションの依存関係まで、各レイヤーを本番環境への投入前に検査します。GitLabのContainer-Scanning CIテンプレートを追加するか、ワンクリックのマージリクエストで有効にできます。

結果はJSONアーティファクトとパイプラインのSecurityタブに表示され、リスクのあるCVEやサポート期限が切れたOSのバージョンを示します。

ベースイメージやOSパッケージに含まれる既知のCVEを検出します。有効にした場合は、JavaやPythonのパッケージなど、言語固有のライブラリの脆弱性も検出します。セキュリティ更新が提供されなくなった、サポート終了後のOSも検出対象です。基盤となるTrivyスキャナーは、NVD、ディストリビューションのセキュリティ情報、GitLab独自のアドバイザリーデータベースを参照し、CVSSスコアと悪用可能性に基づいて脆弱性を特定・分類します。

GitLabの組み込みテンプレートを.gitlab-ci.yml.

include:

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

または、プロジェクトのSecure > Security configurationに移動し、Configure with a merge requestをクリックしてマージします。必要なジョブがパイプラインに追加されます。Dockerイメージをビルドしてプロジェクトのレジストリにプッシュしている場合、追加のスクリプトは不要です

パイプラインの実行後、Build > Pipelinesを開き、対象の実行を選んでSecurityタブを選択します。各検出結果の重大度、CVSSスコア、悪用される可能性(EPSS)、修復方法を確認できます。スキャンレポートの元データ(gl-container-scanning-report.json)とCycloneDX SBOM(gl-sbom-report.cdx.json)は、Job Artifactsから入手できます。

Ultimateプランでは、マージリクエスト内に表示される結果と、デフォルトブランチの統合された脆弱性レポートも確認できます。

はい。各脆弱性の項目には、問題とその影響を説明するDescriptionと、パッケージの更新や設定変更などを示すRecommended remediation stepsが含まれます。Ultimateプランでは、GitLabが自動修復パッチを生成することもできます。修正版に合わせてDockerfileやパッケージのマニフェストを更新するマージリクエストです。

リポジトリのルートにvulnerability-allowlist.ymlを作成します。誤検知と確認したCVE IDを、全体またはイメージごとに記載します。GitLabは該当するCVEを以降のスキャンレポートから除外し、ジョブログで「Approved」としてマークします。実際の問題を隠さず、Securityタブで真のリスクに集中できます。

さらに詳しく見る クラウドセキュリティ

Decorative background gradient

クラウドセキュリティを30分で完全評価。

SentinelOneのエキスパートとのミーティングで、マルチクラウド環境全体にわたるクラウドセキュリティ態勢を評価し、クラウド資産、設定ミス、シークレットスキャンを明らかにし、Verified Exploit Paths™でリスクの優先順位を付けます。
Dark dashboard UI with purple-highlighted nav, summary cards showing 149, 7, 78, 56, 1.2 h, and a status table with linked purple text