GitHub Advanced Security のネイティブ統合を Microsoft Defender for Cloud で設定する

このガイドでは、GitHub Advanced Security (GHAS) とMicrosoft Defender for Cloudを統合し、統合をエンドツーエンドで検証するのに役立つユースケースと統合するためのセットアップ手順とその他のアクションについて説明します。この統合により、ランタイムのリスクとコンテキストを元のコードと関連付けることで、MICROSOFT のクラウドネイティブアプリケーションのセキュリティを最大化し、AI を利用した修復を高速化できます。

このガイドに従うことで、次の操作を行うことができます。

GitHub リポジトリを Defenders for Cloud のカバレッジ用に設定します。
ランタイムリスクファクターを作成します。
Defender for Cloud で実際のユースケースをテストします。
コードをランタイムリソースにリンクします。
GitHubでセキュリティキャンペーンを開始します。このキャンペーンでは、ランタイムコンテキストを使用して GHAS セキュリティアラートに優先順位を付けます。
Defender for Cloud からGitHubの問題を作成して、修復を開始します。
エンジニアリングチームとセキュリティチームの間のループを閉じます。

[前提条件]

特徴	詳細
環境要件	- Defender for Cloud で作成されたコネクタを使用してアカウントをGitHubする - 接続されたリポジトリでの GitHub Advanced Security (GHAS) ライセンス - Defenderサブスクリプションで有効になっているクラウドセキュリティ体制管理 (DCSPM) プラン - Microsoft Security Copilot (AI を利用した自動修復の場合は省略可能)
ロールとアクセス許可	- セキュリティ管理者のアクセス許可 - Azure サブスクリプションのセキュリティ管理者 (Defender for Cloud で結果を表示するため) - GitHub組織の所有者 (リポジトリの接続とセキュリティキャンペーンの構成用)
クラウド環境	- 商用クラウドでのみ利用できます (Azure Government、21Vianet が運営するAzure、またはその他のソブリンクラウドでは使用できません)

環境を準備する

手順 1: GitHub リポジトリを設定し、ワークフローを実行する

統合をテストするには、独自のリポジトリまたはサンプルサンドボックスプロジェクトを使用します。このプロジェクトには、すべての内容を含むテスト GitHub リポジトリがあり、脆弱なコンテナーイメージがビルドされます。

Azure ポータルにサインインします。
Microsoft Defender for Cloud>DevOps security に移動します。
検索バーにコードリポジトリ名を入力します (例: zava-webshop)。
監視している組織に実際に属していることを検証します (例: zava-corporation org)。
リポジトリの結果があるかどうかを確認します。
アドバンスドセキュリティの状態がOnであることを確認します。これは、オンボードされた監視対象のリポジトリで GitHub アドバンスドセキュリティが有効になっていることを示しています>。
リポジトリが見つからない場合は、トラブルシューティングと GitHub コネクタのオンボードに関するMicrosoft Defender for Cloudドキュメントを参照してください。
GitHub コネクタのエージェントレススキャンが有効になっていることを確認します。

手順 2: 環境の準備ができていることを検証する

検証では、コードを実行時の推奨事項に表示し、実行可能な結果を生成するように環境が正しく構成されていることを確認します。この手順の間に、Defender によって次のことが確認されます。

コードから実行時まの完全な可視化

Microsoft Defender for Cloudは、セキュリティの脆弱性についてソースコードリポジトリを継続的に監視します。
コンテナーイメージなどのビルド成果物は、デプロイ前にコンテナーレジストリでスキャンされます。
Kubernetes クラスターにデプロイされたランタイムワークロードは、セキュリティリスクを監視します。
Defender for Cloudは、ビルドとデプロイを通じて、コードからランタイムと戻る各成果物を関連付け、トレースします。

注

次の結果を確認するには、前の手順が適用されてから最大 24 時間かかる場合があります。

GitHubエージェントレススキャンがリポジトリを検出するかどうかをテストします。

Microsoft Defender for CloudCloud セキュリティエクスプローラークエリを実行します。検証クエリは、Defender がパイプラインとワークロードによって生成された成果物を識別できるかどうかをテストします。クエリから結果が返された場合は、スキャンと相関関係が期待どおりに動作していることを示します。

注

結果が返されない場合は、アーティファクトがまだ生成されていない、スキャンが構成されていない、またはアクセス許可が不足していることを示している可能性があります。詳細については、「ユーザーロールとアクセス許可」を参照してください。

Defender for Cloud (Azure Container Registry) がコンテナーイメージをスキャンし、それを使用してコンテナーを作成したことを確認します。
クエリで、特定のデプロイの条件を追加します。
コンテナーが実行されていること、および Defender for Cloud が AKS クラスターをスキャンしたことを確認します。
Defender for Cloud 側でリスク要因が正しく構成されていることを検証します。 Defender for Cloud インベントリページでコンテナー名を検索すると、それが重大としてマークされていることがわかります。

注

この手順は、環境内でリスク要因がまだ構成されていない場合にのみ必要です。既にリスク要因を使用している場合は、[設定] > [リソースの重要度] でそれらの構成を確認できます。

検証が成功すると、推奨事項、キャンペーン、GitHubでの問題生成など、後続の手順で意味のある結果が得られます。

注

リソースをクリティカルとして分類した後、Defender for Cloud がデータをGitHubに送信するまでに最大 12 時間かかることがあります。 詳細情報 を参照してください。

手順 3: GitHub キャンペーンを作成する

スキャンキャンペーンを作成するには、GitHub組織レベルで作業する必要があります。このエクスペリエンスは、個々のリポジトリレベルでは使用できません。

GitHubで、セットアップテストに使用したGitHub組織に移動します。
Security>Campaigns>キャンペーンを作成>コードスキャンフィルターから選択 を選択します。
このキャンペーンは、本当にデプロイされて実行されているコードに属する GHAS の結果に優先順位を付けるのに役立ちます。
キャンペーン の実行時リスク フィルターを選択します。
[>] を選択します。必要な情報を入力し、キャンペーンを発行します。
キャンペーンの進捗を追跡します。

手順 4: 推奨事項の展開

セキュリティの問題の状態を把握するには、実行中の Containers VA 推奨事項のコードからランタイムへの機能と、識別された CVE と Dependabot セキュリティアラートの相関関係を使用します。その後、コードからランタイムへのマッピングに基づいて、解決の推奨事項を関連するエンジニアリングチームに割り当てることができます。

Defender for Cloud ポータルで、[ 推奨事項 ] タブに移動します。
コードリポジトリから作成したコンテナーの名前を検索します。
ソフトウェアの更新に関する推奨事項のいずれかを開きます。推奨事項の名前は Update で始まります
[ 関連する CVE ] タブを選択すると、推奨事項の評価フローの一部としてセキュリティアラートが表示されます。これらのアラートは、エンジニアリングチームが既に認識しているGitHub Advanced Securityの発見に関するサインを提供します。一部の CVE ID には、[関連する GitHub アラート] 列に [GitHubで表示] リンクがあります。

リンクを選択して、関連する GHAS セキュリティアラートを開きます。 (GITHUBで GHAS アラートコンテンツを表示するには、関連するGitHub リポジトリへのアクセス許可が必要です。アクセス許可がない場合は、後で使用するためにリンクをいつでもコピーするか、GitHub管理者に問い合わせてください)。

アラートエンリッチメントがある場合は、エンジニアリングに既に認識されている一致する Dependabot アラートがあります。状態が [アクティブ] の場合、誰も修正していないので、修正のために問題の優先順位を付ける必要があります。

エンリッチメントが見つからない場合、これはエンジニアリングに知られていないランタイムのリスクを示しており、修正の優先順位を付ける必要があります。

次のステップ修正に関連するチームが誰であるかを知る方法を教えてください。修正プログラムのエンジニアリングに役立つコンテキストを知る方法

GitHubの問題を作成する

セキュリティチームとエンジニアリングチームの間のループを閉じるには、エンジニアリングチームが重点を置く必要があるセキュリティの問題に優先順位を付けるGitHubの問題を作成できます。この優先順位付けには、GHAS が取得しなかったものの、直接依存関係の一部ではない CVE ID に対して Defender for Cloud によって検出された結果を渡すことが含まれます。これらの結果には、基本イメージ、オペレーティングシステム、または NGINX などのソフトウェアの脆弱性が含まれる場合があります。

GitHubの問題は、元のコードリポジトリで自動的に生成され、修正とテストを容易にするのに役立つ他のランタイムおよびコンテナー SDLC 関連のコンテキストを含め、推奨事項のスコープ内にあるすべての CVE ID が検出されます。

推奨事項ビューから、修復作業を追跡するためのGitHubの問題を明示的に生成できます。

[Remediation Insights] タブに移動し、コードからランタイムへの図を表示します。この図は、実行中のコンテナーをコードリポジトリ内のコンテナーイメージと、GitHubの元のコードリポジトリにマップします。
1. Remediation Insights タブ内の影響を受ける ランタイム ボックスを確認してください。
2. GitHubの問題が既に存在するかどうかを検証します。 GitHubの問題が既に存在する場合は、ボックスにGitHub アイコンが表示されます。アイコンにカーソルを合わせると、問題の詳細が表示されます。
3. 問題が存在せず、必要なアクセス許可がある場合は、新しいGitHubの問題を生成できます。 [ アクションの実行] を選択します。
4. ポップアップから Generate GitHub issue オプションを選択します。
5. 問題が正常に作成された場合は、問題へのリンクを含むポップアップ通知が表示されます。この問題は、元のコードリポジトリに作成されます。
  
  GitHubの問題リストのスクリーンショットで、Defender for Cloudやセキュリティのようなラベルが付けられた依存関係の未解決の問題を示しています。
注

Generate GitHub問題のオプションが使用できない場合は、必要なGitHubまたはリポジトリのアクセス許可が不足している可能性があります。アクセス権を要求するには、GitHubまたはリポジトリ管理者に問い合わせてください。
1. 所有権と状態の更新の追跡 - GitHubで行われた問題の状態または割り当ての変更がMicrosoft Defender for Cloudに反映され、Recommendations ビューから所有権と修復の進行状況を追跡できます。