GitHubの高度なセキュリティ統合をデプロイする

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

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

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

前提条件

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

環境を準備する

統合を検証する前に、GitHubリポジトリとDefender for Cloudの設定を設定する手順を以下に完了してください。

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

統合をテストするには、自社リポジトリや サンプルサンドボックスプロジェクトを使ってください。 サンドボックスプロジェクトは、脆弱なコンテナイメージを構築するために必要なすべての情報が入ったテスト用GitHubリポジトリを提供します。

  1. Azure portal にサインインする

  2. Microsoft Defender for Cloud>DevOps security に移動します。

  3. 例えば、検索バーにコードリポジトリ名を入力してください。例えば zava-webshopです。

  4. 監視している組織 ( zava-corporation 組織など) に属していることを検証します。

  5. リポジトリに検出事項があるかどうかを確認します。

  6. [Advanced security status]\(高度なセキュリティ\) 状態が [オン] になっていることを確認します。 この設定は、監視対象リポジトリでGitHub Advanced Securityが有効であることを示しています。

  7. リポジトリが見つからない場合は、トラブルシューティングやセットアップのガイダンスとしてGitHubコネクタのオンボーディングクイックスタートをご覧ください。

  8. GitHub コネクタのエージェントレス スキャンが有効になっていることを確認します。

    エージェントレス コードスキャンがオンに切り替え、すべてのスキャナー オプションが有効になっているDefender CSPMのプラン構成のスクリーンショット。

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

この環境検証は、リポジトリとクラウドリソースが正しく設定されていることを確認します。 Defenderが実行時までのコード推奨を示し、有用な結果を生成できるかをチェックします。 環境検証の段階で、Defenderは以下を検証します:

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

注

前の手順を適用してから最大24時間かかることがあります。

コードから実行時間までの完全な可視性を検証する

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

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

Defender for Cloud の Cloud Security Explorer で、コンテナー イメージへの GitHub リポジトリのプッシュに関するクエリを表示しているスクリーンショット。

注

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

  1. Azure Container Registryで、Defender for Cloudがコンテナイメージをスキャンし、それを使ってコンテナを作成したことを検証します。

  2. クエリで、特定のデプロイの条件を追加します。

    Defender for Cloud の Cloud Security Explorer で、脆弱性のあるコンテナー イメージへの GitHub リポジトリのプッシュに関するクエリを表示しているスクリーンショット。

  3. コンテナーが実行されていること、および Defender for Cloud が AKS クラスターをスキャンしたことを確認します。

    脆弱性のあるコンテナー イメージへの GitHub プッシュに関するクエリを表示している Defender for Cloud の Cloud Security Explorer のスクリーンショット。

  4. Defender for Cloud 側でリスク要因が正しく構成されていることを検証します。 Defender for Cloudのインベントリページでコンテナ名を検索してください。 それがクリティカル(重大)と表示されているのを確認するはずです。

注

この手順は、環境内でリスク要因がまだ構成されていない場合にのみ必要です。 すでにリスク要因を使っている場合は、「 設定>リソースクリティカルリティ」で設定を確認することができます。

検証が正常に完了すると、推奨事項、キャンペーン、GitHub Issue の生成などの次のステップで、有意義な結果を得られます。

注

リソースをクリティカルとして分類した後、Defender for Cloud が GitHub にデータを送信するまでに最大 12 時間かかることがあります。 詳細については、「 Dependabotの優先順位付け」および「コードスキャンアラート」をご覧ください。

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

スキャンキャンペーンを作成するには、GitHub組織レベルで作業してください。 このエクスペリエンスは、個々のリポジトリ レベルでは使用できません。

  1. GitHub で、セットアップ テストに使用した GitHub 組織に移動します。

  2. Security>Campaigns>キャンペーンを作成>コードスキャンフィルターから選択 を選択します。

    ランタイムリスクキャンペーンは、実際にデプロイされ実行されているコードに属するGitHub Advanced Security(GHAS)の発見を優先順位付けするのに役立ちます。

  3. キャンペーン の実行時リスク フィルターを選択します。

    フィルター バー、フィルター ボタン、成果物メタデータによるフィルター処理に関するヒントを含むGitHub コード スキャン キャンペーンの作成のスクリーンショット。

    ランタイム リスク フィルターと選択可能なリスク要因メニューが開いたGitHub キャンペーンの作成における高度なフィルター ダイアログのスクリーンショット。

  4. [>] を選択します。 必要な情報を入力し、キャンペーンを発行します。

  5. キャンペーンの進捗を追跡します。

    期限切れの状態、キャンペーンの進行状況バー、重要なアラートリスト、フィルター オプションを示すGitHub キャンペーン ページのスクリーンショット。

ステップ4:推奨事項に基づいて行動する

実行中のコンテナー向け VA 推奨事項、コードからランタイムへの関連付け機能、および特定された CVE と Dependabot セキュリティ アラートの関連付けを利用して、セキュリティ問題の状況を把握しましょう。 その後、コードからランタイムへのマッピングに基づいて、解決の推奨事項を関連するエンジニアリング チームに割り当てることができます。

  1. Defender for Cloud ポータルで、[ 推奨事項 ] タブに移動します。

  2. コード リポジトリから作成したコンテナーの名前を検索します。

  3. アップデートソフトウェアのおすすめの一つを開いてください。 推薦名は 「更新」で始まります。

  4. 関連CVEを選択します。

    セキュリティ アラートは、推奨事項の評価フローの一部として表示されます。 これらのアラートは、エンジニアリングに既に知られているGitHub Advanced Security の結果に関する兆候を提供します。 一部のCVE IDには「関連GitHubアラート」欄に「GitHubで見る」リンクがあります。

     CVE-2024-21409 アラート、修正状態、CVSS スコア、およびGitHubアラートの詳細ポップアップを示す [Defender for Cloud結果] タブのスクリーンショット。

リンクを選択して、関連する GHAS セキュリティ アラートを開きます。 GitHubでGASアラート内容を見るには、該当するGitHubリポジトリへのアクセス権が必要です。 アクセス権限がない場合は、次回の利用のためにリンクをコピーするか、GitHub管理者に連絡することもできます。

もし「関連GitHubアラート」欄にマッチしたDependabotアラートが表示されていれば、その脆弱性はすでにエンジニアリング側に把握されています。 アラートステータスが 「アクティブ」であれば、まだ誰も修正しておらず、問題を優先して修正する必要があります。

列に一致するGitHubアラートが表示されない場合、そのCVEはエンジニアリング チームが把握していないランタイム リスクを表しており、修正を優先する必要があります。

GitHubの問題を作成する

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

GitHubの問題は、修正とテストに役立つ他のランタイムおよびコンテナー SDLC 関連のコンテキストを含め、推奨事項のスコープで見つかったすべての CVE ID を含むソース コード リポジトリで自動的に生成されます。

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

  1. Remediation Insightsにアクセスし、コードから実行時間までのダイアグラムをご覧ください。 この図は、実行中のコンテナーをコード リポジトリ内のコンテナー イメージと、GitHubの元のコード リポジトリにマップします。

    [ランタイム] ボックスでリスク レベルと [アクションの実行] メニューが開いている、コードからランタイムへの図を示す Remediation Insights のスクリーンショット。

    1. [ Remediation Insights ] タブで、影響を受ける [ランタイム ] ボックスを確認します。

    2. GitHubの問題が既に存在するかどうかを検証します。 GitHubの問題が既に存在する場合は、ボックスにGitHub アイコンが表示されます。 アイコンにカーソルを合わせると、問題の詳細が表示されます。

    3. 問題が存在せず、必要なアクセス許可がある場合は、新しいGitHubの問題を生成できます。 [ アクションの実行] を選択します。

    4. ポップアップから Generate GitHub issue オプションを選択します。

    5. 問題が正常に作成された場合、問題へのリンクを含むポップアップ通知が表示されます。 この問題は、元のコード リポジトリに作成されます。

      GitHubの問題リストのスクリーンショットで、Defender for Cloudやセキュリティのようなラベルが付けられた依存関係の未解決の問題を示しています。

    注

    もし「GitHub issue生成」オプションが利用できない場合、GitHubやリポジトリの権限が持たない可能性があります。 アクセス権を要求するには、GitHubまたはリポジトリ管理者に問い合わせてください。

    Defender for Cloudラベルとセキュリティ ラベルとのオープン依存関係に関して生成されたGitHubの問題を示すスクリーンショット。

    1. 所有権やステータスの更新を追跡しましょう。 GitHubで発行ステータスや割り当ての変更は、Microsoft Defender for Cloudに反映されます。 この事実により、 推奨 事項の視点から所有権や修復の進捗を追跡できます。

      Microsoft Defender for Cloudの推奨事項ページのスクリーンショットで、高リスクの問題とGitHub問題の詳細のポップアップを示しています。

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

もしGitHub Copilotライセンスをお持ちなら、GitHubのコーディングエージェントの助けを借りて問題を解決できます:

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