Microsoft Defender for Cloud の GitHub Advanced Security ネイティブ統合をセットアップ

このガイドでは、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する - GHAS ライセンス - サブスクリプションで有効になっている Defender Cloud Security Posture Management (DCSPM) - Microsoft Security Copilot (自動修復の場合は省略可能)
ロールとアクセス許可	- セキュリティ管理者のアクセス許可 - Azure サブスクリプションのセキュリティ管理者 (Defender for Cloud で結果を表示するため) - GitHub組織の所有者
クラウド環境	- 商用クラウドでのみ利用できます (Azure Government、21Vianet が運営するAzure、またはその他のソブリンクラウドでは使用できません)

環境を準備する

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

統合をテストするには、独自のリポジトリまたはすべてのコンテンツを既に含むリポジトリGitHub例を使用して、脆弱なコンテナーイメージを構築します。リポジトリを設定する前に、次の点を確認してください。

Defender for Cloud ポータルで使用するGitHub組織のコネクタを定義します。 GitHub環境を Microsoft Defender for Cloud。
GitHub コネクタのエージェントレスコードスキャンを構成します。エージェントレスコードスキャンの構成 (プレビュー) の手順に従います。
統合に使用するリポジトリはプライベートです。

サンプルリポジトリを使用する場合は、GitHub組織に次のリポジトリを複製します:build25-woodgrove/mdc-customer-playbook。このリポジトリは、Defender for Cloud と GHAS の統合をテストするためのリポジトリです。 GHAS が有効になっており、Defender CSPM が有効になっているAzure テナントにオンボードされます。

リポジトリで、次の手順に従います。

[設定] に移動します。
左側のウィンドウで、シークレットと変数Actions を選択します。次に、新しいリポジトリシークレットを選択します。

GitHubで新しいリポジトリシークレットを作成するための選択項目のスクリーンショット

リポジトリまたは組織レベルで次のシークレットを追加します。

Variable	Description
`ACR_ENDPOINT`	コンテナーレジストリのログインサーバー
`ACR_USERNAME`	コンテナーレジストリのユーザー名
`ACR_PASSWORD`	コンテナーレジストリのパスワード

注

名前は自由に選択でき、特定のパターンに従う必要はありません。

この情報は、Azure ポータルで次の手順に従って確認できます。

デプロイするコンテナーレジストリを選択します。
[ 設定] で、[ アクセスキー] を選択します。 [ アクセスキー ] ウィンドウには、ログインサーバー、ユーザー名、およびパスワードのキーが表示されます。

Azure ポータルでのコンテナーレジストリのアクセスキーを一覧表示するペインのスクリーンショット

リポジトリで[ アクション]を選択します。
[ビルドと ACR へのプッシュ] ワークフローを選択し、[ワークフローの実行] を選択します。
イメージがコンテナーレジストリにデプロイされたことを確認します。

サンプルリポジトリの場合、イメージは mdc-mock-0001 という名前のレジストリに、タグ mdc-ghas-integration が含まれている必要があります。
クラスターで実行中のコンテナーと同じイメージをデプロイします。この手順を完了する 1 つの方法は、クラスターに接続し、コマンドを使用することです。 Azure Kubernetes Service (AKS) の例を次に示します。
1. クラスターサブスクリプションを設定します。
```
az account set --subscription $subscriptionID
```
2. クラスターの資格情報を設定します。
```
az aks get-credentials --resource-group $resourceGroupName --name $kubernetesClusterName --overwrite-existing
```
3. イメージをデプロイします。
```
kubectl run $containerName --image=$registryName.azurecr.io/mdc-mock-0001:mdc-ghas-integration
```

手順 2: リスク要因の例を作成する (ビジネスクリティカルなルール)

Defender for Cloud がこの統合に対して検出するリスク要因の 1 つは、ビジネスの重要度です。組織は、リソースにビジネスクリティカルとしてラベルを付けるルールを作成できます。

Defender for Cloud ポータルで、[リソースの重要度] に移動します。
右側のウィンドウで、リンクを選択してMicrosoft Defenderを開きます。

Microsoft Defender ポータルを開くための選択を示す Defender for Cloud インターフェイスのスクリーンショット
[ 新しい分類の作成] を選択します。

新しい分類を作成するためのボタンのスクリーンショット。
名前と説明を入力します。
クエリビルダーで、[ クラウドリソース] を選択します。
リソース名を、検証のためにクラスターにデプロイしたコンテナーの名前と同じ名前に設定するクエリを記述します。次に、[次へ] を選択します。

&C2>Microsoft Defender クエリビルダーのスクリーンショットで、クラウドリソースにリソース名フィルターが適用されています。
Preview Assets ページで、もし Microsoft Defender がリソースを既に検出している場合、コンテナーの名前は資産の種類が K8s-container または K8s-pod として表示されます。

名前がまだ表示されていない場合でも、次の手順に進みます。 Microsoft Defenderは、コンテナーを検出した後、コンテナーに重要度ラベルを適用します。このプロセスには最大で 24 時間かかります。
重要度レベルを選択し、分類規則を確認して送信します。

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

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

この手順の間に、Defender によって次のことが確認されます。

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

注

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

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

注

結果が返されない場合は、アーティファクトがまだ生成されていない、スキャンが構成されていない、またはアクセス許可が不足していることを示している可能性があります。詳細については、「ユーザーロールとアクセス許可」を参照してください。
Defender for Cloud (Azure Container Registry) がコンテナーイメージをスキャンし、それを使用してコンテナーを作成したことを確認します。クエリで、特定のデプロイの条件を追加します。
コンテナーが実行されていること、および Defender for Cloud が AKS クラスターをスキャンしたことを確認します。
Defender for Cloud 側でリスク要因が正しく構成されていることを検証します。 Defender for Cloud インベントリページでコンテナー名を検索すると、それが重大としてマークされていることがわかります。

注

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

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

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

ワークフローは、リスク要因 (ビジネスクリティカル) の 1 つで実行中のコンテナーを作成するイメージをデプロイするため、開発者はGitHubでリスク要因を確認できます。

注

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

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

GitHubで、セットアップテストに使用したGitHub組織に移動します。
SecurityCampaignsキャンペーンを作成コードスキャンフィルターから選択を選択します。このキャンペーンでは、環境全体で評価および追跡されるクラウドで検出された成果物 (コンテナーイメージやワークロードなど) を定義します。
次のキャンペーンを作成します。このキャンペーンでは、リポジトリからデプロイされたイメージが重要なリソースに関連付けられている重大度が中程度のオープンアラートが表示されます。このキャンペーンでは、テストリポジトリを検出する必要があります。

開いているアラート、重大度、実行時リスクに関するフィルターが適用されたGitHubキャンペーンのスクリーンショット
[キャンペーンとして公開] を選択します。
必要な情報を入力し、キャンペーンを発行します。

手順 5: 推奨事項を評価する

コードからランタイムへの推奨事項とセキュリティアラートを使用して、セキュリティの問題の状態を把握します。その後、Defender for Cloud の Dependabot セキュリティアラートと一致する一般的な脆弱性と露出 (CVE) ID の間の接続の助けを借りて、関連するエンジニアリングチームに解決の推奨事項を割り当てることができます。

コードからランタイムまでの推奨事項

コードからランタイムへの推奨事項を表示するには:

Defender for Cloud ポータルで、[ 推奨事項 ] タブに移動します。
作成したコンテナーの名前を検索します。次に、更新ソフトウェアの推奨事項のいずれかを開き、推奨事項の名前は Update で始まります。

サンプルリポジトリを使用した場合は、ブレース展開の更新に関する推奨事項を確認します。
[Remediation Insights] タブに移動し、ランタイムダイアグラムのコードを表示します。この図は、実行中のコンテナーをコードリポジトリ内のコンテナーイメージと、GitHubの配信元のコードリポジトリにマップします。

キャンペーンが実行されると、Defender は、クラウドの結果をコードとビルド成果物と関連付ける実行時の推奨事項にコードを表示します。

次のビューは、影響を受ける資産とリスクシグナルに関するコンテキストを示しています。このビューは、アクションを実行する前に推奨事項が生成された理由を理解するのに役立ちます。

リンクされた開発フェーズの図を示す [Remediation Insights] タブのスクリーンショット。

セキュリティのアラート

セキュリティアラートは、推奨事項の評価フローの一部として表示されます。これらのアラートは、アクティブなリスクに関する追加のコンテキストを提供し、修復に優先順位を付けるのに役立ちますが、GitHubの問題は自動的に作成されません。

関連付けられている CVE タブを選択します。一部の CVE ID には、関連する GitHub アラート列に GitHub で表示リンクがあることに注意してください。
リンクを選択して、関連する GHAS セキュリティアラートを開きます。 (GITHUBで GHAS アラートコンテンツを表示するには、関連するGitHubリポジトリへのアクセス許可が必要です。そうでない場合は、GitHub管理者に問い合わせてください)。

関連するGitHubアラートへのリンクを示す関連付けられたCVEタブのスクリーンショット

GitHubの問題を作成する

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

GitHubの問題は、推奨事項のスコープで見つかったすべての CVE ID で自動的に生成されます。元のリポジトリにおいて、Dependabotアラートの一致の有無に関わらず推奨される内容には、他のランタイムコンテキストも含まれています。

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

関連する更新ソフトウェアの推奨事項を開きます。
[Remediation Insights] タブを選択します。
影響を受ける [ランタイム ] ボックスを確認します。
GitHubの問題が既に存在するかどうかを検証します - GitHubの問題が既に存在する場合は、ボックスにGitHub アイコンが表示されます。アイコンにカーソルを合わせると、問題の詳細が表示されます。
問題が存在せず、必要なアクセス許可がある場合は、新しいGitHubの問題を生成できます。
[ アクションの実行] を選択します。
ポップアップから Generate GitHub issue オプションを選択します。
問題が正常に作成された場合は、問題へのリンクを含むポップアップ通知が表示されます。
この問題は、元のコードリポジトリに作成されます。

注

Generate GitHubの問題 オプションを使用できない場合は、必要なGitHubまたはリポジトリのアクセス許可がない可能性があります。
アクセス権を要求するには、GitHubまたはリポジトリ管理者に問い合わせてください。
問題がGitHubユーザーに割り当てられている場合、またはその状態が変更された場合、更新プログラムは Defender for Cloud ポータルに反映されます。

所有権と状態の更新の追跡 - GitHubで行われた問題の状態または割り当ての変更がMicrosoft Defender for Cloudに反映され、所有権と修復の進行状況を追跡できます。

エージェント型修正を行う

GitHub側で、GitHub Copilot ライセンスをお持ちの場合は、GitHub コーディングエージェントの助けを借りて問題を解決できます。

GitHubコーディングエージェントを問題に割り当てます。
生成された修正プログラムを確認します。
修正が妥当と思われる場合は、適用します。
Defender for Cloud が問題の状態を [終了済み] に更新することを確認します。

GitHubのAdvanced SecurityのMicrosoft Defender for Cloud（プレビュー版）との統合については何ですか?
Microsoft Defender for Cloud DevOps セキュリティの概要
Quickstart: GitHub環境を Microsoft Defender for Cloud
エージェントレスコードスキャンを構成する (プレビュー)

フィードバック

このページはお役に立ちましたか?

Last updated on 2026-03-05