Microsoft Defender for CloudでGitHub Advanced Security（GHAS）integrationを導入する目的は、GitHub上の脆弱性アラートを「実際にクラウド上で動いているワークロードのリスク」と結び付け、優先順位を付けて修正することです。2026年5月28日更新の公式ドキュメントでは、GitHubリポジトリの準備、Defender for Cloudでの検証、GitHub Campaigns、推奨事項からのGitHub Issue作成まで、展開後に確認すべき流れが整理されています。(Microsoft Learn)
管理者が最初に見るべきポイントは、GHASライセンスの有無、GitHub connector、DCSPMプラン、agentless scanning、GitHub側の権限です。開発者側では、GitHub Issueに渡されるCVE、実行環境のコンテキスト、コードとコンテナイメージの対応関係を確認し、単なるアラート対応ではなく「本番影響のある修正」を優先する運用に切り替えることが重要です。
Microsoft Defender for CloudとGHAS統合で何が変わるのか
今回確認すべきポイントは、新しい脆弱性スキャナーを単体で追加することではありません。Microsoft Defender for Cloudが持つクラウド実行環境の情報と、GitHub Advanced Securityのコードスキャン・Dependabotアラートをつなぎ、セキュリティチームと開発チームが同じ文脈で修正を進められるようにする点です。
従来は、GitHub上のアラートを見ても「その脆弱性が本番に出ているのか」「どのAKSワークロードやコンテナに影響するのか」「どのチームが直すべきか」が分かりにくいケースがありました。GHAS integrationでは、ソースコード、ビルド成果物、コンテナイメージ、実行中のワークロードを関連付け、実行環境のリスクを基に優先度を判断できます。Microsoftの説明でも、この統合はソースコードと実行中のクラウドワークロードを相互にリンクし、実際に本番影響のある脆弱性を優先できる仕組みとして位置付けられています。(Microsoft Learn)
| 観点 | 従来起きやすい課題 | GHAS統合後に確認できること |
|---|---|---|
| 脆弱性の優先順位 | CVSSや重大度だけで判断し、修正順が現場感とずれる | インターネット露出、機密データ、重要リソースなどのRuntime Risk Factorsを踏まえて判断できる |
| 担当チームの特定 | コンテナやクラウドリソースからリポジトリをたどるのに時間がかかる | 実行中のワークロードからGitHubの元リポジトリへ戻れる |
| 修正依頼 | セキュリティチームが別チケットで依頼し、開発側の文脈が不足する | Defender for Cloudの推奨事項からGitHub Issueを作成し、CVEや実行環境の情報を渡せる |
| 進捗管理 | GitHub側とDefender側で状態が分断される | GitHub Issueのステータスや担当状況をDefender for Cloud側でも追跡できる |
影響範囲はGitHub、Azure、コンテナ実行環境まで広がる
GHAS integrationの影響範囲は、GitHubのリポジトリだけではありません。Defender for CloudのDevOps security、Azureサブスクリプション、コンテナレジストリ、AKSなどの実行環境、GitHub Campaigns、GitHub Issue運用まで関係します。
特に影響を受けるのは、次のような環境です。
| 対象 | 確認すべき内容 |
|---|---|
| GitHub Organization | Defender for Cloud GitHub connectorが作成されているか。対象リポジトリが接続されているか |
| GitHubリポジトリ | GHASが有効か。Defender for CloudのDevOps security画面でAdvanced security statusがOnになっているか |
| Azureサブスクリプション | Defender Cloud Security Posture Management、つまりDCSPMプランが有効か |
| コンテナレジストリ | コンテナイメージがDefender for Cloudでスキャンされ、実行環境と関連付けられるか |
| AKSなどの実行環境 | 実行中のワークロードがDefender for Cloudで監視されているか |
| GitHub Campaigns | OrganizationレベルでRuntime Risksフィルターを使ったキャンペーンを作れるか |
| GitHub Issue運用 | 推奨事項からIssueを生成できる権限と、担当者に渡す運用ルールがあるか |
注意したいのは、GHAS integrationは商用クラウドで利用する前提として説明されており、Azure Government、21Vianet運営のAzure、その他のソブリンクラウドは対象外とされています。GitHub connector自体の可用性と、GHAS integrationの可用性を同一視しないようにしてください。(Microsoft Learn)
導入前に満たすべき前提条件
公式手順では、GitHub accountにDefender for Cloudのconnectorが作成されていること、接続リポジトリにGHASライセンスがあること、サブスクリプションでDCSPMプランが有効であることが前提として示されています。AIによる自動修復を使う場合はMicrosoft Security Copilotが任意の要件として挙げられています。(Microsoft Learn)
権限面では、Azure側でSecurity Admin権限、サブスクリプション上のセキュリティ検出結果を参照できる権限、GitHub側でOrganization Owner権限が必要です。特にGitHub Campaignsの作成やリポジトリ接続は、個別リポジトリの開発者権限だけでは不足する場合があります。
管理者向けの事前チェック
| チェック項目 | 判断基準 | よくある失敗 |
|---|---|---|
| GitHub connector | Defender for CloudのEnvironment settingsにGitHub connectorが存在する | 別テナントや別サブスクリプションに作成しており、対象リポジトリが見えない |
| GHAS | DevOps security画面でAdvanced security statusがOn | GHASライセンスはあるが、対象リポジトリで有効化されていない |
| agentless scanning | GitHub connectorでagentless scanningが有効 | コネクタは作成済みだがスキャンが動いていない |
| DCSPM | 対象サブスクリプションでDCSPMプランが有効 | 推奨事項やRuntime Risk Factorsが期待通り出ない |
| GitHub権限 | Organization Ownerまたは必要な管理権限がある | Campaign作成やIssue生成ができない |
| 対象クラウド | 商用クラウドで利用している | ソブリンクラウド環境で同じ手順を前提にしてしまう |
展開手順は「接続して終わり」ではなく、検証まで行う
公式ドキュメントの展開フローでは、まずAzure portalでMicrosoft Defender for CloudのDevOps securityを開き、対象リポジトリが監視対象のOrganizationに属しているか、検出結果があるか、Advanced security statusがOnかを確認します。リポジトリが見つからない場合は、GitHub connectorのオンボーディングやトラブルシューティングを確認する流れです。(Microsoft Learn)
ここで重要なのは、リポジトリが見えているだけでは不十分という点です。Defender for Cloudがコード、ビルド成果物、コンテナイメージ、実行中のワークロードを結び付けられる状態にしなければ、GHAS統合の本来の価値は出ません。
展開後の確認フロー
| 手順 | 確認する場所 | 成功の目安 |
|---|---|---|
| リポジトリ確認 | Microsoft Defender for Cloud > DevOps security | 対象リポジトリが表示され、Organizationが正しい |
| GHAS確認 | DevOps securityのAdvanced security status | Onになっている |
| agentless scanning確認 | GitHub connector設定 | agentless scanningが有効 |
| コードから実行環境の検証 | Cloud Security Explorer | パイプライン成果物やワークロードに関連するクエリ結果が返る |
| リスク要因の確認 | Defender for Cloud Inventory、Settings > Resource criticality | 重要リソースとして分類され、期待するリスクが付与されている |
| GitHub Campaign確認 | GitHub Organization > Security > Campaigns | Runtime Risksフィルターでキャンペーンを作成できる |
| 修正連携確認 | Defender for Cloud Recommendations | GitHub alertやGitHub Issue生成の導線が確認できる |
検証結果がすぐ出ない場合もあります。公式ドキュメントでは、前段の設定後に結果が表示されるまで最大24時間かかる場合があること、重要リソースに分類した後にDefender for CloudからGitHubへデータが送られるまで最大12時間かかる場合があることが示されています。(Microsoft Learn)
そのため、展開直後に「何も出ないから失敗」と判断するのは早計です。まずは対象リポジトリでビルド成果物が作られているか、コンテナが実行されているか、AKSやコンテナレジストリ側のスキャンが成立しているかを確認してください。
GitHub CampaignsはOrganizationレベルで設計する
GHAS統合では、GitHub Campaignsを使って、実行環境のリスクを踏まえたセキュリティ修正キャンペーンを作れます。公式手順では、GitHub OrganizationのSecurity > Campaignsから「From code scanning filters」を選び、Runtime Risksフィルターを使ってキャンペーンを作成する流れが示されています。なお、この操作はOrganizationレベルで行うもので、個別リポジトリレベルの体験としては提供されていません。(Microsoft Learn)
実務では、いきなり全社リポジトリを対象にするよりも、外部公開サービスや決済・認証・個人情報を扱うサービスから始める方が安全です。最初のキャンペーンで大量のアラートを出しすぎると、開発チームが「また全部Critical扱いか」と受け止め、優先順位付けの信頼性が下がります。
Campaigns設計の判断基準
| 判断軸 | 優先して対象にすべき例 |
|---|---|
| 外部公開 | インターネットから到達可能なWeb API、公開フロントエンド |
| データ重要度 | 顧客情報、決済情報、認証情報、業務機密を扱うサービス |
| 実行中の有無 | すでにAKSや本番環境で稼働しているコンテナ |
| 修正可能性 | CODEOWNERSや担当チームが明確なリポジトリ |
| 運用負荷 | まず1〜3チームで試験展開し、Issue運用を固められる範囲 |
推奨事項からGitHub Issueを作成し、修正の流れを閉じる
Defender for CloudのRecommendationsでは、実行中のコンテナに関する脆弱性推奨事項から、関連するCVEやDependabot security alertsを確認できます。Related GitHub Alerts列に「View on GitHub」リンクがある場合は、該当するGHASアラートをGitHubで開けます。ただし、GitHub側で対象リポジトリへのアクセス権がなければ、アラート内容は表示できません。(Microsoft Learn)
重要なのは、GHASが検出した依存関係の脆弱性だけでなく、Defender for Cloudが実行環境から見つけたリスクもIssue化できる点です。公式ドキュメントでは、GHASが直接拾わない可能性があるベースイメージ、OS、NGINXなどのソフトウェアに関するCVEも、Defender for Cloud側で検出される場合があると説明されています。(Microsoft Learn)
開発チームにとっては、GitHub Issueに「なぜこのCVEを今直すべきか」という実行環境の文脈が入ることが大きなメリットです。単に「Highだから直してください」ではなく、「このコンテナは本番で稼働しており、インターネット露出があり、該当イメージにCVEが含まれている」という説明が付けば、スプリント内での優先順位を決めやすくなります。
Issue生成で確認すべきポイント
| 確認項目 | 実務上の見方 |
|---|---|
| Remediation Insights | 実行中コンテナ、コンテナイメージ、元リポジトリの対応関係が自然か |
| 既存Issueの有無 | 同じワークロードやCVEで重複Issueを作っていないか |
| Generate GitHub issue | ボタンや選択肢が表示されるか。表示されない場合は権限不足を疑う |
| Issueの作成先 | 期待するソースコードリポジトリにIssueが作成されているか |
| CVEの範囲 | 直接依存関係だけでなく、ベースイメージやOS由来のCVEも含まれていないか |
| ステータス同期 | GitHub側の担当者・状態変更がDefender for Cloudに反映されるか |
Generate GitHub issueの選択肢が表示されない場合、GitHubまたはリポジトリ側の権限が不足している可能性があります。セキュリティ管理者だけで解決しようとせず、GitHub Organization Ownerやリポジトリ管理者と事前に権限設計を確認してください。(Microsoft Learn)
agentless code scanningの制限を理解して展開する
GHAS統合の展開手順では、GitHub connectorでagentless scanningが有効になっていることを確認します。Defender for Cloudのagentless code scanningは、CI/CDパイプラインを変更せずにコード、オープンソース依存関係、IaCをスキャンできる仕組みです。GitHub connectorやAzure DevOps connectorを通じて動作し、結果はDefender for Cloudの推奨事項として表示されます。(Microsoft Learn)
ただし、agentless code scanningは万能ではありません。公式ドキュメントではPublic Previewの制限として、バイナリスキャンは行わないこと、スキャン頻度は有効化時と1日1回であること、1GB未満のリポジトリが対象であること、対象ブランチは通常mainなどのデフォルトブランチのみであることが示されています。(Microsoft Learn)
そのため、次のような環境では追加対策が必要です。
| 状況 | 推奨される考え方 |
|---|---|
| リリースブランチで長期保守している | agentless scanningだけでなく、リリースブランチ側のGHAS設定やパイプラインスキャンを検討する |
| ビルド時にブロックしたい | agentless scanningはビルドを止められないため、CI/CD内のスキャンやポリシー運用を併用する |
| 大規模モノレポを使っている | 1GB制限やスキャン時間を確認し、分割や対象範囲設定を検討する |
| コンテナイメージやバイナリも厳密に見たい | コンテナレジストリスキャンやパイプライン内スキャンと役割分担する |
| 新規リポジトリが頻繁に増える | inclusion modeでは自動検出されない点に注意し、スコープ設計を見直す |
agentless scanningとin-pipeline scanningは競合するものではありません。公式ドキュメントでも、agentless scanningは広い範囲を少ない負荷でカバーする用途、in-pipeline scanningはパイプラインに統合して詳細に制御する用途として整理されています。特に、ビルド失敗条件を設けたい場合はin-pipeline scanningの検討が必要です。(Microsoft Learn)
管理者が移行・展開時に注意すべきこと
既にGHASを使っている組織では、GHAS統合の導入を「既存アラートの置き換え」と考えない方が安全です。正しくは、既存のGHASアラートに実行環境の優先順位を重ねる運用変更です。
まずは、現行のGHAS運用で使っているルール、Dependabot alerts、CODEOWNERS、既存Issue管理、SLAを棚卸ししてください。そのうえで、Defender for Cloudから作成されるGitHub Issueをどのラベルで扱うか、誰がトリアージするか、重複Issueをどう閉じるかを決めておく必要があります。
移行時に決めておくべき運用ルール
| 項目 | 決めるべき内容 |
|---|---|
| 優先度の基準 | GHAS重大度、CVSS、Runtime Risk Factors、外部公開有無のどれを上位基準にするか |
| Issueの担当 | CODEOWNERS、サービスオーナー、SRE、AppSecのどこに初期割り当てするか |
| 重複管理 | 既存Dependabot alert、既存GitHub Issue、Defender生成Issueの重複をどう扱うか |
| 修正期限 | Critical、High、インターネット露出ありなどの条件別にSLAを決めるか |
| 例外承認 | 修正できないCVE、誤検知、互換性問題を誰が承認するか |
| 終了条件 | GitHub Issueを閉じるだけでよいのか、Defender for Cloudの推奨事項解消まで見るのか |
特に失敗しやすいのは、セキュリティチームがIssueを大量に作成し、開発チームが背景を理解しないまま放置するパターンです。最初の展開では、1つの本番サービスを対象に、Defender for Cloudの推奨事項、GitHub alert、GitHub Issue、修正、再検出までを通しで確認するのが現実的です。
開発者が確認すべき修正ポイント
開発者は、GitHub Issueに記載されたCVEだけを見て修正を始めるのではなく、どの実行環境に出ている問題なのかを確認する必要があります。Remediation Insightsのコードから実行環境までの対応関係を見れば、修正対象がアプリケーションコード、依存パッケージ、Dockerfile、ベースイメージ、Kubernetesマニフェストのどこにあるのかを判断しやすくなります。
たとえば、Dependabot alertでライブラリ更新が提案されている場合は、manifestやlockfileの更新で済むことがあります。一方、Defender for Cloud側でベースイメージ由来のCVEが示されている場合は、アプリケーションのpackage.jsonやpom.xmlを直しても解消しません。DockerfileのFROM行、OSパッケージ、ベースイメージのタグ、再ビルドと再デプロイまで確認する必要があります。
GitHub Copilotライセンスがある場合、GitHub側でcoding agentをIssueに割り当て、生成された修正案をレビューして適用する流れも公式手順に含まれています。ただし、生成された修正をそのまま適用するのではなく、依存関係の互換性、テスト結果、コンテナ再ビルド後のスキャン結果を確認してからマージするべきです。(Microsoft Learn)
導入後に見るべき実務チェックリスト
GHAS統合を展開したら、次の項目を順番に確認してください。
| タイミング | 確認項目 | 完了の目安 |
|---|---|---|
| 導入直後 | GitHub connector、GHAS、DCSPM、agentless scanning | 対象リポジトリがDevOps securityに表示される |
| 数時間後 | Inventory、Cloud Security Explorer | コード、成果物、実行環境の関連が見える |
| 最大24時間後 | Recommendations | コンテナやリポジトリに関する推奨事項が表示される |
| リスク分類後 | Resource criticality、GitHub側のRuntime Risks | 重要リソースの情報がGitHubの優先順位付けに反映される |
| Campaign作成時 | GitHub OrganizationのSecurity > Campaigns | Runtime Risksフィルターでキャンペーンを公開できる |
| 修正依頼時 | Remediation Insights、GitHub Issue | 元リポジトリにIssueが作成され、CVEと実行環境の文脈が入っている |
| 修正後 | Defender for CloudとGitHub双方の状態 | Issue状態と推奨事項の解消状況が追跡できる |
まずは小さく展開し、優先順位付けの精度を検証する
Microsoft Defender for CloudとGitHub Advanced Securityの統合は、アラート数を増やすための仕組みではなく、修正すべき脆弱性を実行環境の文脈で絞り込むための仕組みです。管理者は、GHASライセンス、GitHub connector、DCSPM、agentless scanning、権限、商用クラウド要件を確認してください。開発者は、GitHub Issueに渡されるCVEだけでなく、コンテナイメージ、実行中ワークロード、ベースイメージ、依存関係のどこを直すべきかを見極める必要があります。
最初の一歩としては、全リポジトリへの一括展開ではなく、外部公開されている重要サービスを1つ選び、リポジトリ表示、Cloud Security Explorerの検証、GitHub Campaign、Issue生成、修正後のステータス同期までを通しで確認するのがおすすめです。そこで運用ルールを固めてから、対象Organizationやリポジトリを広げると、セキュリティチームと開発チームの摩擦を抑えながら実効性のあるDevSecOps運用に移行できます。
コメント