結論から言うと、Microsoft Defender for Cloud と GitHub Code Security / GitHub Advanced Security の連携GAは、脆弱性を「コードで検出されたか」だけでなく、「実際にクラウドで稼働しているか」「インターネット公開や機密データ処理などのリスクがあるか」で優先順位付けできるようにする更新です。管理者は DCSPM、GitHub コネクタ、GitHub Advanced SecurityまたはGitHub Code Securityの有効化、権限、リポジトリと実行環境のマッピング を確認する必要があります。開発者は、GitHub上のアラートやキャンペーンを、実行時リスクに基づいて絞り込めるようになるため、対応すべき脆弱性を判断しやすくなります。
Microsoft Learnのリリースノートでは、このネイティブ統合のGAが2026年5月3日付で掲載され、GitHub Changelogでも2026年5月5日に一般提供として案内されています。この記事では、2026年6月上旬時点の公式情報を基に、Microsoft Defender for Cloudの変更点、影響範囲、管理者と開発者が確認すべき展開上の注意点を整理します。(Microsoft Learn)
Microsoft Defender for CloudとGitHub Code Security連携GAの要点
今回のポイントは、コード、ビルド成果物、クラウド実行環境のリスクを1つの流れで見られるようになることです。
従来のAppSec運用では、GitHubのcode scanningやDependabotで検出された脆弱性と、Microsoft Defender for Cloudで見えるクラウド側の露出リスクが別々に扱われがちでした。その結果、「本番で動いていないコードの警告」と「インターネットに公開された本番ワークロードの脆弱性」が同じ重みで並び、開発チームがどこから直すべきか判断しにくい状況が起きていました。
GAとなった連携では、Defender for Cloudのランタイムリスク情報をGitHub Advanced Security側のアラートに結び付け、実際に運用環境へ到達している脆弱性を優先しやすくします。Microsoft Learnでは、インターネット公開、機密データ、重要リソース、横移動可能性といったリスク要因がGHASの結果に反映されると説明されています。(Microsoft Learn)
なお、Microsoft Learnでは前提ライセンスとして「GitHub Advanced Security（GHAS）」と表記されています。一方で、GitHub側ではGitHub Code Securityがcode scanning、プレミアムDependabot機能、dependency reviewなどを含む製品として整理されています。契約や管理画面の名称が組織によって異なる場合があるため、社内では「GHAS」「GitHub Code Security」「GitHub Secret Protection」のどのSKUを使っているかを確認しておくと混乱を避けられます。(GitHub Docs)
何が変わったのか
今回のGAで重要なのは、単にDefender for Cloudの画面にGitHubの情報が表示されることではありません。修復の優先順位を、クラウドでの実害に近いリスクから決められるようになることです。
| 観点 | これまで起こりやすかった課題 | GA連携後に期待できること | 確認ポイント |
|---|---|---|---|
| アラートの優先順位 | 重要度Highのアラートが多く、どれから直すべきか判断しづらい | 実際にデプロイ済み、公開済み、機密データに関係する脆弱性を優先しやすい | GitHub側でruntime-risk系フィルターが使えるか |
| コードとクラウドのひも付け | 脆弱なコンテナーがどのリポジトリ由来か追跡に時間がかかる | 実行中ワークロードから元のリポジトリやビルド成果物へたどれる | イメージ、パイプライン、リポジトリのマッピング精度 |
| セキュリティチームと開発チームの連携 | Defender側の推奨事項を開発者の作業に落とし込みにくい | Defender for CloudからGitHub issueを生成し、修復担当へ渡せる | GitHub組織・リポジトリの権限、CODEOWNERS運用 |
| キャンペーン運用 | 大量のアラートを一括で投げるだけになりやすい | GitHub Security Campaignsで実行時リスクに基づく対象化ができる | 組織レベルでキャンペーンを作れる権限 |
| AI修復 | 修正案は出せても、どの修正を優先するか判断が別工程 | Copilot Autofixやcoding agentを、優先度の高いissueに使いやすい | 自動修正のレビュー、テスト、承認プロセス |
GitHub Changelogでは、Defender for Cloudがクラウド環境で実行されている内容をソースコードへ関連付け、GitHubのcode scanning、Dependabot、security campaignsでランタイムコンテキストを使った絞り込みができると説明されています。具体的には、has:deployment や runtime-risk:internet-exposed、runtime-risk:sensitive-data といったフィルターが案内されています。(The GitHub Blog)
影響を受ける組織と受けにくい組織
この更新の影響が大きいのは、GitHubで開発し、コンテナーやクラウドワークロードを本番環境へ継続的にデプロイしている組織です。特に、AKSなどのKubernetes環境、コンテナーイメージ、複数チームが管理するマイクロサービス、インターネット公開アプリケーションを持つ企業では、脆弱性対応の優先順位付けに直接効きます。
一方、すべての組織がすぐに恩恵を受けるわけではありません。GitHubを使っていない、GitHub Advanced SecurityやGitHub Code Securityを有効化していない、Defender Cloud Security Posture Management（DCSPM）を使っていない、またはGitHubリポジトリと実行環境の関係が追跡できない場合は、まず基盤整備が必要です。
| 対象 | 影響度 | 理由 |
|---|---|---|
| GitHubでアプリを開発し、Azureやマルチクラウドへデプロイしている組織 | 高 | コードからクラウドまでのリスクをつなげて見られる |
| コンテナーイメージをCI/CDでビルドし、Kubernetesへ展開している組織 | 高 | 実行中ワークロードと元リポジトリの関連付けが重要になる |
| AppSecチームとクラウド運用チームが分かれている組織 | 高 | GitHub issueやキャンペーンで修復作業を開発側に渡しやすい |
| GitHubは使っているがGHAS / Code Security未導入の組織 | 中 | ライセンスと有効化範囲の確認が先になる |
| GitHub以外のリポジトリ中心の組織 | 低〜中 | Defender for CloudのDevOps security全体の整理は必要だが、この連携の直接効果は限定的 |
| Azure Governmentやソブリンクラウド利用組織 | 低 | この統合は商用クラウドのみ利用可能とされている |
Microsoft Learnの前提条件では、GitHubコネクタ、GHASライセンス、DCSPMプラン、Security Admin権限、GitHub organization owner、商用クラウドでの利用が示されています。Azure Government、21Vianetが運用するAzure、その他のソブリンクラウドでは利用できない点は、グローバル企業や公共系案件では必ず確認すべきです。(Microsoft Learn)
管理者が最初に確認すべき前提条件
導入前に、まず次の5点を確認してください。ここを曖昧にしたまま展開すると、「GitHubにアラートが出ない」「Defender for Cloudからリポジトリにたどれない」「issue生成ボタンが出ない」といったトラブルにつながります。
| 確認項目 | 見る場所 | 判断基準 |
|---|---|---|
| DCSPMプラン | Microsoft Defender for Cloudのプラン設定 | 対象サブスクリプションで有効になっているか |
| GitHubコネクタ | Defender for Cloud > Environment settings | 対象GitHub組織が接続されているか |
| GHAS / GitHub Code Security | GitHub organization / repositoryのSecurity設定 | 対象リポジトリで有効か |
| 権限 | Azure RBAC、GitHub organization権限 | Azure側はSecurity Admin、GitHub側はorganization ownerなどが必要 |
| クラウド種別 | 利用テナント・リージョン | 商用クラウドであるか |
GitHub環境の接続は、Defender for CloudのEnvironment settingsからAdd environmentを選び、GitHubを選択して認可・GitHubアプリのインストールを進めます。公式手順では、保護対象を漏らさないため、Defender for Cloud GitHubアプリにはすべてのリポジトリへのアクセスを付与することが推奨されています。(Microsoft Learn)
ただし、実務ではいきなり全社展開するよりも、まず本番影響の大きい1〜2アプリでパイロットを行うのが安全です。最初の対象は、次の条件を満たすリポジトリを選ぶと検証しやすくなります。
- GitHub Actionsなどでコンテナーイメージをビルドしている
- Azure Container Registryなどにイメージを格納している
- AKSなどの実行環境にデプロイされている
- Defender for Cloudでワークロードのリスクが見えている
- CODEOWNERSや担当チームが明確である
GitHubコネクタ設定で失敗しやすいポイント
GitHubコネクタの設定では、権限と対象範囲の設計が重要です。
特に注意したいのは、同じGitHub organizationを複数のAzureテナントやコネクタに重複して接続しないことです。Microsoft Learnでは、Defender for Cloudの高度なDevOps posture機能を正しく動作させるため、GitHub organizationは作成先Azureテナントに1インスタンスのみオンボードする必要があると説明されています。(Microsoft Learn)
また、オンボード直後に結果が表示されないことがあります。公式ドキュメントでは、オンボード後にリポジトリやビルドなどのDevOpsリソースがInventoryやDevOps securityページへ表示されるまで最大8時間かかる場合があるとされています。さらに、セキュリティスキャンの推奨事項によっては追加のワークフロー設定が必要です。(Microsoft Learn)
| 症状 | よくある原因 | 対応 |
|---|---|---|
| リポジトリがDefender for Cloudに出ない | GitHubアプリの対象外、組織選択漏れ、反映待ち | GitHubアプリのインストール範囲と最大8時間の反映時間を確認 |
| GitHub側にランタイムリスクが出ない | DCSPM未有効、agentless scanning未有効、マッピング未成立 | 対象サブスクリプションとGitHubコネクタ設定を確認 |
| issue生成ができない | GitHubまたはリポジトリ権限不足 | GitHub organization ownerやリポジトリ管理者に確認 |
| アラートが多すぎる | すべての脆弱性を同列に扱っている | runtime-riskやdeployment状態で絞り込む |
| 担当者に届かない | CODEOWNERSやリポジトリ所有者が未整備 | リポジトリ単位の責任者を先に定義する |
開発者が見るべきGitHub側の変化
開発者にとっての変化は、Defender for Cloudを直接見なくても、GitHub上で「この脆弱性は本番で動いているのか」「外部公開されているのか」「機密データを扱うワークロードなのか」を判断しやすくなる点です。
GitHub Changelogでは、Defender for CloudのランタイムコンテキストがGitHubへ取り込まれ、組織レベルのアラート一覧やキャンペーン作成フローで利用できると説明されています。たとえば、runtime-risk:internet-exposed でインターネット公開リスクを持つアラートを優先し、runtime-risk:sensitive-data で機密データに関係するアラートを絞り込む運用が考えられます。(The GitHub Blog)
開発チームでは、次のような運用ルールを作ると効果が出やすくなります。
| 場面 | 推奨する判断 |
|---|---|
| 週次の脆弱性対応 | まずデプロイ済みかつruntime-riskありのアラートを確認する |
| 緊急対応 | internet-exposed、sensitive-data、critical resourceに関係するものを優先する |
| スプリント計画 | GitHub Security Campaignsで対象アラートをまとめ、修復期間を決める |
| レビュー | Copilot Autofixやcoding agentの修正案をそのままマージせず、テストとコードレビューを必須にする |
| 例外管理 | すぐ直せないものは期限、代替策、リスク所有者をissueに残す |
ここで重要なのは、AIによる修正支援を「自動で安全に直してくれる機能」と見なさないことです。公式手順でも、GitHub Copilotのcoding agentで修正する場合は、生成された修正をレビューし、妥当なら適用する流れが示されています。セキュリティ修正は依存関係、互換性、テスト、デプロイ手順に影響するため、最終判断は人間のレビューとCI/CDの検証で行うべきです。(Microsoft Learn)
Defender for Cloud側で確認すべき画面と設定
管理者は、少なくとも次の画面を確認してください。
| 画面 | 確認すること |
|---|---|
| Environment settings | GitHubコネクタが作成され、対象組織が接続されているか |
| DevOps security | 対象リポジトリが検出され、Advanced security statusがOnか |
| Cloud Security Explorer | コード、ビルド成果物、実行ワークロードの相関が取れているか |
| Recommendations | コンテナーやワークロードの脆弱性推奨事項にGitHub関連情報が表示されるか |
| Inventory | 対象ワークロードの重要度やリスク要因が期待どおりか |
| Resource criticality | 重要リソースの分類が設定されているか |
Microsoft Learnの展開手順では、DevOps securityで対象リポジトリを検索し、Advanced security statusがOnであること、GitHubコネクタでagentless scanningが有効であることを確認する流れが示されています。また、コードからランタイムまでの可視性確認では、リポジトリ、コンテナーイメージ、Kubernetes上の実行ワークロードがDefender for Cloudで相関されることを検証します。(Microsoft Learn)
注意点として、設定後すぐにすべての情報がそろうとは限りません。公式手順では、前提設定後に結果が見えるまで最大24時間かかる場合があり、リソースをcriticalとして分類した後にそのデータがGitHubへ送られるまで最大12時間かかる場合があるとされています。(Microsoft Learn)
GitHub issue生成と修復フローの設計
この連携の価値は、可視化だけではなく、修復作業を開発チームの通常ワークフローへ乗せられる点にあります。
Defender for CloudのRecommendationsから対象の推奨事項を開き、関連するCVEやGitHubアラートを確認できます。さらに、Remediation Insightsでコードからランタイムまでの図を確認し、必要な権限があればGitHub issueを生成できます。Microsoft Learnでは、issueは元のコードリポジトリに作成され、CVE IDやランタイム、コンテナーSDLCに関するコンテキストを含められると説明されています。(Microsoft Learn)
実務では、issueを作れることよりも、issueが作られた後に誰が、いつまでに、どの基準で閉じるかを決めておくことが重要です。
| 決めるべき項目 | 具体例 |
|---|---|
| 担当者 | CODEOWNERS、サービスオーナー、SRE、AppSec担当 |
| 優先度 | internet-exposedかつcriticalなら48時間以内に一次判断 |
| 完了条件 | 修正PRのマージ、再スキャンでの解消、例外承認の記録 |
| 例外条件 | 互換性問題、ベンダー修正待ち、補完統制あり |
| 追跡指標 | 未対応issue数、平均修復日数、期限超過率、マッピング成功率 |
Defender for CloudとGitHubの状態同期により、GitHub側のissueステータスや割り当て変更をDefender for Cloud側から追跡できます。これにより、セキュリティチームがExcelや別チケットへ手作業で転記する運用を減らせます。(Microsoft Learn)
展開前に見直したいセキュリティ運用ルール
GA連携を有効にするだけでは、脆弱性管理は改善しません。むしろ、リスク情報が増えることで、運用ルールが曖昧な組織では混乱が増える可能性があります。
展開前に、次のルールを明文化しておくことをおすすめします。
| 項目 | ルール例 |
|---|---|
| 優先順位 | 本番稼働、インターネット公開、機密データ、重要リソース、横移動可能性を優先軸にする |
| 対応期限 | Criticalは即日判断、Highは次回スプリント内、Medium以下はキャンペーンでまとめる |
| issue作成基準 | runtime-riskがあるものはDefender for CloudからGitHub issue化する |
| AI修正の扱い | Copilot Autofixの提案は必ずレビューと自動テストを通す |
| 例外承認 | 期限、補完統制、リスク所有者を残し、定期的に再評価する |
| メトリクス | アラート数より、実行中ワークロードに関係する未修復リスクを追う |
特に避けたいのは、「GitHub側でCriticalだからすべて最優先」とする運用です。今回の連携の狙いは、コード上の深刻度だけでなく、クラウド上の露出やデータ感度を合わせて判断することです。たとえば、同じCVEでも、社内検証環境で停止中のイメージと、外部公開された決済APIの本番コンテナーでは、対応順が変わります。
30日で始める現実的な展開プラン
全社一括展開よりも、対象を絞って「見える化、優先順位付け、issue化、修復、再確認」までを小さく回す方が成功しやすくなります。
| 期間 | 実施内容 | 成果物 |
|---|---|---|
| 1〜3日目 | 対象サブスクリプション、GitHub組織、リポジトリ、ライセンスを棚卸し | 対象範囲リスト |
| 4〜7日目 | GitHubコネクタ、DCSPM、GHAS / Code Security、agentless scanningを確認 | 接続済みGitHub環境 |
| 8〜14日目 | Cloud Security ExplorerとDevOps securityでマッピングを検証 | コードからランタイムまでの確認結果 |
| 15〜21日目 | runtime-riskを使ったGitHub Security Campaignsを作成 | 優先対応キャンペーン |
| 22〜30日目 | Defender for CloudからGitHub issueを生成し、修復と再スキャンを確認 | 運用手順と改善点 |
最初のパイロットでは、対象を広げすぎないことが重要です。おすすめは、外部公開されているが担当チームが明確なアプリケーションを1つ選ぶことです。ここでリポジトリ、ビルド、コンテナーイメージ、実行環境、issue、修復PRまでの流れを確認できれば、ほかのチームへ展開しやすくなります。
導入判断の基準
この連携は、単なるセキュリティ機能追加ではなく、DevSecOpsの業務設計に関わる更新です。次のいずれかに当てはまる場合は、優先的に検証する価値があります。
| 導入優先度が高いケース | 理由 |
|---|---|
| GitHub上のアラートが多すぎて対応順を決められない | ランタイムリスクで絞り込める |
| セキュリティチームと開発チームのチケット連携が手作業 | GitHub issue化で責任の所在を明確にしやすい |
| コンテナーやKubernetesの本番ワークロードが多い | コードから実行環境までの追跡が効く |
| インターネット公開サービスや機密データ処理が多い | 実害に近いリスクを優先できる |
| 経営層へセキュリティ負債の説明が必要 | 「本番で動く重要リスク」に絞って説明しやすい |
逆に、GitHub Code SecurityやGHASの導入前、クラウド側のDefender for Cloud運用が未成熟、リポジトリ所有者が不明、CI/CDの成果物管理が曖昧な状態では、まず基盤整備を優先すべきです。連携機能を先に有効化しても、正しい担当者へ修復作業を渡せなければ効果は限定的です。
管理者と開発者が今すぐ確認すべきこと
まず管理者は、対象サブスクリプションでDCSPMが有効か、GitHubコネクタが正しく作成されているか、対象リポジトリでGHASまたはGitHub Code Securityが有効かを確認してください。次に、Defender for CloudのDevOps securityとCloud Security Explorerで、コード、ビルド成果物、実行ワークロードの対応関係が見えるかを検証します。
開発者は、GitHubのcode scanningやDependabotアラートを従来どおり確認するだけでなく、deployment状態やruntime-riskのフィルターを使い、実際に本番環境へ到達しているリスクを優先する運用へ切り替える必要があります。Copilot Autofixやcoding agentを使う場合も、セキュリティ修正は必ずレビュー、テスト、段階的なデプロイを通すべきです。
今回のGAで得られる最大の価値は、「アラートを増やすこと」ではなく、「本当に直すべきリスクを、開発チームが使うGitHubのワークフローへ届けること」です。最初の一歩として、外部公開されている重要アプリを1つ選び、Defender for CloudからGitHub issueを生成して修復完了まで追跡できるかを確認してください。そこまで回せれば、Microsoft Defender for CloudとGitHub Code Security連携は、単なる監視強化ではなく、コードからクラウドまでのリスク管理を実務に落とし込む仕組みとして機能します。
コメント