Microsoft Defender for Cloud DevOps Securityの公式情報が更新され、「既存の接続設定を変更する必要があるのか」「どのリポジトリまで保護されるのか」と気になっている管理者も多いでしょう。
今回の情報だけを理由に、緊急パッチの適用やサービス停止を伴う作業を行う必要はありません。 今回明確になったのは、Azure DevOps、GitHub、GitLabを一元管理し、コードの問題を稼働中のクラウドリソースと関連付けて修復につなげる、Microsoft Defender for Cloud DevOps Securityの利点と論理的な構成です。
ただし、すでに利用している組織は、コネクタの認証アカウント、対象リポジトリの網羅性、スキャン方式、プルリクエスト注釈、監査ログの見え方を確認すべきです。特に、Azure DevOpsコネクタを個人アカウントで認可している場合や、検出件数が少ないことを「安全」と判断している場合は、優先的な見直しが必要です。
Microsoft Defender for Cloud DevOps Securityの「利点とアーキテクチャ更新」とは
日付の扱いには注意が必要です。対象となるMicrosoft Learnの日本語版には「2026年7月7日更新」、英語版には「2026年6月17日更新」と表示されています。また、Defender for Cloudの新機能リリースノートには、7月8日付のDevOps Securityに関するGA、プレビュー、強制的な仕様変更は掲載されていません。
そのため、本件は「2026年7月8日に実質更新として確認された公式説明の整理」であり、新しい保護機能が自動的に有効化された、または既存環境に破壊的変更が入ったと捉えないのが妥当です。(Microsoft Learn)
公式情報から読み取れるポイントは、次のとおりです。
| ポイント | 公式情報で示された内容 | 管理者にとっての意味 |
|---|---|---|
| 統一された可視性 | Azure DevOps、GitHub、GitLabを中央コンソールで管理 | 複数の開発基盤をDefender for Cloud側で横断確認できる |
| 開発段階でのリスク発見 | コード、シークレット、依存関係、IaCの問題を確認 | 本番環境へ入る前に問題を修正しやすくなる |
| コードからクラウドへの関連付け | コードの問題とクラウド側のコンテキストを組み合わせる | 実際に稼働している重要なシステムに影響する問題を優先できる |
| 開発者への修復依頼 | PR注釈やカスタムワークフローを利用 | セキュリティ担当者だけで抱えず、開発ツール上で修復を依頼できる |
| カバレッジの可視化 | 高度なセキュリティ機能やPR注釈の状態を表示 | 未設定のリポジトリや部分的な保護を発見できる |
Defender for CloudのDevOps Security画面では、スキャン結果、セキュリティ構成の推奨事項、高度なセキュリティ機能の適用状況、オンボードされたリポジトリなどを確認できます。(Microsoft Learn)
Microsoft Defender for Cloud DevOps Securityが保護する範囲
Microsoft Defender for Cloud DevOps Securityは、単にソースコードの脆弱性を探すだけのサービスではありません。開発環境の設定、CI/CDパイプライン、リポジトリ、IaC、クラウド上の稼働リソースまでを関連付けて管理することが目的です。
主な保護対象は次のとおりです。
| 保護対象 | 確認できる主な問題 |
|---|---|
| DevOpsインベントリ | 未管理の組織、プロジェクト、グループ、リポジトリ |
| リポジトリのセキュリティ設定 | 既定ブランチの保護、強制プッシュ、レビュー要件 |
| パイプライン設定 | シークレットへの過剰なアクセス、すべてのパイプラインに許可された接続 |
| ソースコード | 静的解析で検出されるコード上の脆弱性 |
| シークレット | トークン、秘密鍵、接続情報などの露出 |
| OSS依存関係 | 脆弱性が報告されたパッケージやライブラリ |
| IaCテンプレート | Terraform、ARMテンプレートなどの構成ミス |
| コンテナー関連情報 | イメージと生成元リポジトリ、パイプライン、稼働リソースの関連付け |
| APIセキュリティ | 対応する環境で検出されたAPIテストの問題 |
Azure DevOpsでは、フォークのビルドにシークレットを渡す設定、すべてのパイプラインから利用できるサービス接続、セキュアファイル、シークレット変数を含む変数グループなども評価対象です。GitHubでは、シークレットスキャン、ブランチ保護、Actionsの権限、組織レベルのシークレット公開範囲などが推奨事項として提示されます。(Microsoft Learn)
重要なのは、コネクタを作成しただけで、すべてのコードスキャンが自動的に有効になるわけではないことです。インベントリや一部の構成評価はコネクタによって利用できますが、コード、依存関係、シークレットなどの検出には、別途スキャナーや対応ライセンスが必要になる場合があります。
アーキテクチャは4つの層に分けて考える
Microsoft Defender for Cloud DevOps Securityの構成は、次の流れで整理すると理解しやすくなります。
Azure DevOps・GitHub・GitLab → DevOpsコネクタ → インベントリ・構成情報・スキャン結果 → Microsoft Defender for Cloud → クラウド側のリスク情報と関連付け → 推奨事項・PR注釈・ワークフロー・外部出力
接続層：DevOpsコネクタ
最初の層は、Azure DevOps、GitHub、GitLabとDefender for Cloudを接続するコネクタです。
コネクタは組織、グループ、プロジェクト、リポジトリなどを検出し、Defender for Cloudのインベントリに登録します。Azure DevOpsコネクタは、Azure上ではMicrosoft.Security/securityConnectorsリソースとして作成されます。
Azure DevOpsでは、接続時に認可したアカウントの権限を使って、リポジトリ情報の取得、ビルドメタデータの参照、PR注釈、エージェントレスコードスキャンなどが実行されます。(Microsoft Learn)
検査層：コードや構成を調べるスキャナー
コネクタとは別に、実際にコードや依存関係を検査する仕組みが必要です。
| 方式 | 主な対象 | 強み | 注意点 |
|---|---|---|---|
| エージェントレスコードスキャン | Azure DevOps、GitHub | パイプラインを変更せず広い範囲をスキャン | プレビュー機能。既定ブランチ中心で、バイナリは対象外 |
| Microsoft Security DevOps Extension／Action | Azure Pipelines、GitHub Actions | パイプライン実行時に検査し、開発者へ早く返せる | パイプラインごとの導入と設定が必要 |
| GitHub Advanced Security | GitHub | CodeQL、シークレット、依存関係の検出 | 対応ライセンスと機能の有効化が必要 |
| GitHub Advanced Security for Azure DevOps | Azure DevOps | コード、シークレット、依存関係の結果を統合 | 対象リポジトリでの有効化が必要 |
| GitLabのセキュリティ機能 | GitLab | GitLab側の検出結果をDefender for Cloudで確認 | GitLab Ultimateが必要 |
エージェントレスコードスキャンは、パイプライン変更なしで導入できる一方、現在は既定ブランチのみ、1GB未満のリポジトリ、バイナリスキャン非対応などの制限があります。コードとIaCのスキャンは初回接続後と原則1日1回、リポジトリやパイプラインの体制評価は接続後と約8時間ごとに行われます。(Microsoft Learn)
一方、パイプライン内スキャンはビルドごとに実行でき、バイナリやコンテナーイメージなども含めた柔軟な検査が可能です。重大度に応じてビルドを失敗させる運用も設定できます。
文脈化層：コードと稼働リソースを関連付ける
Defender CSPMを有効にすると、ソースコードの問題を、実際に稼働しているクラウドリソースの状態と関連付けられます。
たとえば、同じ脆弱性でも次の条件があるリソースは優先度が高くなります。
- インターネットから到達できる
- 機密情報を扱っている
- 重要システムとして分類されている
- 攻撃者が横展開できる経路上にある
これにより、単純に脆弱性の件数だけを見るのではなく、「本番環境に到達しており、悪用された場合の影響が大きい問題」から修復できます。コードとクラウドの関連付け、攻撃パス分析、Cloud Security Explorer、PR注釈などの高度な機能には、有料のDefender CSPMプランが必要です。(Microsoft Learn)
修復層：開発者の作業場所へ問題を戻す
検出結果はDefender for Cloudの推奨事項として表示するだけでなく、PR注釈やワークフローを通じて開発者へ渡せます。
Azure DevOpsではMicrosoft Security DevOps拡張機能とブランチのビルド検証、GitHubではGitHub Advanced Securityとワークフロー設定が必要です。
GitLabは接続したリポジトリの検出結果をDefender for Cloudで確認できますが、GitLabのマージリクエストにインライン注釈を表示する機能には対応していません。GitLabを利用する組織は、チケット作成や通知ワークフローなど、別の連携経路を用意する必要があります。(Microsoft Learn)
管理者設定で確認すべきポイント
コネクタの権限を必要最小限にする
接続に必要な主な権限は次のとおりです。
| プラットフォーム | Azure側の権限 | DevOps側の権限 |
|---|---|---|
| Azure DevOps | Subscription ContributorまたはSecurity Admin | Project Collection Administrator |
| GitHub | コネクタを作成できるContributor権限 | Organization Owner |
| GitLab | コネクタを作成できるContributor権限 | Group Owner |
| 検出結果の閲覧 | Security Reader | 原則として変更権限は不要 |
Azure DevOpsでは、Project Collection Administratorに加えて、BasicまたはBasic + Test Plansのアクセスレベルが必要です。Stakeholderだけでは不足します。また、Azure DevOps組織でサードパーティーアプリケーションのOAuthアクセスを有効にする必要があります。
閲覧担当者にサブスクリプション全体の強い権限を付与する必要はありません。リソースグループまたはコネクタのスコープにSecurity Readerを割り当てることで、権限を抑えられます。(Microsoft Learn)
Azure DevOpsは個人アカウントで認可しない
Azure DevOpsコネクタで特に重要なのが、認可に使用するアカウントです。
Defender for Cloudが実行した次の操作は、コネクタを認可したアカウントの操作としてAzure DevOpsに記録されます。
- リポジトリの読み取り
- ビルドメタデータの取得
- PR注釈の追加
- エージェントレスコードスキャン
- APIを使ったインベントリの更新
これらはAzure DevOpsの監査ログ、使用状況ダッシュボード、PRタイムラインに表示されます。個人アカウントを使うと、退職、異動、権限変更、MFA設定の変更によって自動処理が停止する可能性があります。
MDC-DevOps-Connectorのような専用サービスアカウントを用意し、必要最小限の権限を付与する運用が適しています。認可アカウントが削除されたりアクセス権を失ったりした場合は、コネクタを再認可するまで自動処理が停止します。(Microsoft Learn)
自動検出の範囲を確認する
コネクタ作成時には、既存の組織だけを対象にするか、将来作成される組織やグループも自動検出するかを選択できます。
既存環境で確認したいのは、次の3つの数です。
- DevOps管理台帳にあるリポジトリ数
- コネクタが検出したリポジトリ数
- 実際にスキャン機能が有効なリポジトリ数
この3つが一致しない場合、接続漏れ、アクセス権不足、アプリの対象範囲、スキャナー未設定のいずれかが疑われます。
Azure DevOpsとGitHubでは、オンボード後にリソースがインベントリへ表示されるまで最大8時間程度かかる場合があります。接続直後に表示されないからといって、すぐにコネクタを作り直すのは避けましょう。(Microsoft Learn)
同じ組織を重複接続しない
高度なDevOpsセキュリティ機能を正常に動作させるには、同じAzure DevOps組織、GitHub組織、GitLabグループを、同一Azureテナント内で複数のコネクタに重複して接続しないことが重要です。
サブスクリプションや担当部署ごとにコネクタを分ける場合も、1つのDevOps組織をどのコネクタが管理するのかを先に決めてください。(Microsoft Learn)
リージョンとGitHubのデータ所在地を確認する
公式のサポート一覧では、DevOps Securityの対応リージョンとしてEast Asia、Australia East、Canada Central、East US、Central US、North Europe、West Europe、Sweden Central、UK Southなどが挙げられています。
日本語圏で注意したいのは、一覧にJapan EastやJapan Westが明記されていない点です。Azureポータルで実際に選択できるリージョンと、最新のサポート表を導入前に確認してください。
また、データ所在地を設定したGitHub Enterprise Cloudインスタンスは、現時点ではDefender for DevOpsのサポート対象外とされています。(Microsoft Learn)
監査と検知にはどのような影響があるか
Azure DevOpsの監査ログにコネクタの操作が増える
Azure DevOpsでは、Defender for Cloudによる読み取りやPR注釈が、認可アカウントの操作として記録されます。
SOCや内部監査部門は、専用アカウントから発生する次の操作を正常な動作として識別できるようにしておく必要があります。
- 定期的なリポジトリ参照
- ビルド情報の取得
- PRへのコメント追加
- コード取得を伴うスキャン
- API使用量の増加
ただし、専用アカウントから通常と異なる時間帯に大量の操作が発生した場合まで無条件に除外してはいけません。アカウント名だけで監視対象外にするのではなく、操作内容、対象組織、接続元、頻度を含めてベースライン化するのが安全です。
Defender for CloudによるAPI呼び出しは、認可アカウントのAzure DevOpsグローバル消費上限に含まれます。通常はサービス側で調整されますが、大規模環境では使用量も確認しておきましょう。(Microsoft Learn)
検出件数がゼロでも安全とは限らない
検出結果が少ない場合は、次のどちらなのかを切り分ける必要があります。
- 実際に問題が少ない
- スキャン対象や検出機能が不足している
Defender for CloudのDevOpsインベントリでは、高度なセキュリティ状態がOn、Off、Partially enabled、N/Aで表示されます。
Partially enabledは、一部のスキャン機能だけが無効になっている状態です。N/Aは、Defender for Cloudが有効化状態を取得できていないことを示します。どちらも「問題なし」という意味ではありません。
なお、高度なセキュリティ状態の表示はAzure DevOpsとGitHubが中心です。GitLabでは同じ情報が表示されないため、GitLab側のライセンスやスキャン実行状況も併せて確認する必要があります。(Microsoft Learn)
Secure ScoreだけではDevOpsリスクを追跡できない
Microsoftの公式リファレンスでは、DevOpsの推奨事項はCloud Secure Scoreに影響しないと説明されています。
そのため、Secure Scoreが変化していなくても、次の問題が新たに発生している可能性があります。
- リポジトリにシークレットが追加された
- 脆弱な依存パッケージが導入された
- IaCテンプレートに構成ミスが入った
- ブランチ保護が解除された
- パイプラインのシークレット公開範囲が広がった
Secure ScoreだけをKPIにしている組織は、DevOps Securityの推奨事項、重大度別件数、未解決期間、対象リポジトリ数を別の指標として管理してください。(Microsoft Learn)
PR注釈はリポジトリ全体の検出結果ではない
PR注釈に表示されるのは、基本的にプルリクエストで変更された差分に関係する問題です。ファイル内に以前から存在するすべての脆弱性が、毎回PRへ表示されるわけではありません。
したがって、PRに注釈がなかったことを理由に、リポジトリ全体が安全だと判断してはいけません。Defender for Cloudの推奨事項とリポジトリ全体のスキャン結果も確認する必要があります。(Microsoft Learn)
SIEMへ送る場合は推奨事項も監視する
Defender for Cloudのアラートと推奨事項は、Log AnalyticsやAzure Event Hubsへ継続的にエクスポートできます。Microsoft SentinelなどのSIEMで一元監視する場合は、ランタイムのセキュリティアラートだけでなく、DevOps関連の推奨事項も対象に含めてください。
ストリーミングでは、リソースの正常性状態が更新されたタイミングで情報が送信されます。週次スナップショットも選択できるため、リアルタイム対応と監査用記録を分けて設計できます。(Microsoft Learn)
2026年7月31日までに個別推奨事項への移行も確認する
今回の公式説明更新とは別に、同時期の重要な変更として、Defender for Cloudの「グループ化された推奨事項」から「個別推奨事項」への移行があります。
グループ化された推奨事項は、2026年7月31日に非推奨となる予定です。Microsoft Defender for DevOpsの検出結果は、次のようなカテゴリーへ移行します。
| 検出内容 | 推奨事項カテゴリー |
|---|---|
| APIセキュリティ | ApiVulnerabilities |
| 依存関係の脆弱性 | SoftwareUpdate |
| コードの脆弱性 | CodeVulnerabilities |
| IaCの構成ミス | IacVulnerabilities |
| シークレット | ExposedSecrets |
次の仕組みで古い推奨事項IDやサブアセスメントを参照している場合は、移行対応が必要です。
- Azure Resource Graphのクエリ
- KQLクエリ
- 独自ダッシュボード
- 継続的エクスポートのフィルター
- ガバナンスルール
- 除外ルール
- Logic Appsや外部SOARの自動化
- 推奨事項IDを固定したスクリプト
従来のmicrosoft.security/assessments/subassessmentsを前提とした処理は、microsoft.security/assessmentsとproperties.metadata.recommendationCategoryを使う構成へ見直します。
個別推奨事項への移行後は、表示件数やクエリ結果が増える可能性があります。これはリスクが急増したことを意味するとは限りません。従来まとめられていた複数の検出結果が、1件ずつ表示されるためです。(Microsoft Learn)
自社で対応が必要かを判断する
| 現在の状況 | 対応優先度 | 必要な対応 |
|---|---|---|
| Azure DevOps、GitHub、GitLabを利用していない | 低 | 今回の更新に対する作業は不要 |
| 対象サービスを利用しているがDefender for Cloudへ未接続 | 中 | セキュリティ要件と費用を確認し、導入を検討 |
| コネクタを個人アカウントで認可している | 高 | 専用アカウントへの移行と再認可 |
| 台帳上のリポジトリ数とインベントリ数が合わない | 高 | スコープ、権限、GitHub App、OAuth設定を確認 |
高度なセキュリティ状態がOffまたはPartially enabled | 高 | 必要なスキャナーやライセンスを有効化 |
状態がN/Aのリポジトリが多い | 高 | コネクタのアクセス権と情報取得状態を調査 |
| Secure Scoreだけを監視している | 高 | DevOps推奨事項を別のKPIやSIEM監視へ追加 |
| GitLabでPR注釈を利用したい | 中 | チケット作成や通知による代替フローを構築 |
| 旧推奨事項IDを自動化で使用している | 最優先 | 2026年7月31日までにカテゴリー方式へ移行 |
| 専用アカウント、全リポジトリ、スキャン、通知を確認済み | 低 | 定期レビューと証跡保存を継続 |
優先して実施したい対応
対象リポジトリを棚卸しする
まず、Azure DevOps、GitHub、GitLabで管理している組織、プロジェクト、グループ、リポジトリの一覧を用意します。
そのうえで、Defender for CloudのDevOpsインベントリと照合してください。少なくとも次の項目を記録します。
- プラットフォーム名
- 組織またはグループ名
- リポジトリ名
- コネクタ名
- Azureサブスクリプション
- リソースグループ
- コネクタのリージョン
- 認可アカウント
- 高度なセキュリティ状態
- PR注釈の状態
- 使用しているスキャン方式
コネクタの認証主体を確認する
Azure DevOpsでは、認可アカウントが有効か、必要な権限を維持しているかを確認します。
個人アカウントの場合は、専用アカウントへの切り替えを計画してください。単にアカウント名を変更するのではなく、次の点も確認します。
- MFAや条件付きアクセスの影響
- パスワードや資格情報の更新方法
- 退職・異動時に削除されない管理方法
- 監査ログ上の識別ルール
- API使用量の監視
- 障害時の再認可手順
スキャンカバレッジを確認する
各リポジトリについて、何がどの仕組みで検査されているかを明確にします。
たとえば「GitHubコネクタがある」だけでは不十分です。コードはCodeQL、シークレットはSecret Scanning、依存関係はDependabot、IaCはMicrosoft Security DevOps Actionまたはエージェントレススキャンというように、検出元を対応付けます。
エージェントレススキャンだけを使用する場合は、既定ブランチ以外、1GB以上のリポジトリ、バイナリなどが監視対象外にならないか確認してください。
高リスクの問題から修復する
最初に対応すべきなのは、シークレットの露出と、パイプラインから重要リソースへ過剰にアクセスできる設定です。
推奨する優先順位は次のとおりです。
- 公開されたトークン、秘密鍵、パスワードの失効と再発行
- すべてのパイプラインから利用できるサービス接続の制限
- セキュアファイルやシークレット変数の公開範囲縮小
- 既定ブランチの保護とレビュー要件の有効化
- 本番環境へ到達しているコード脆弱性の修正
- 脆弱な依存パッケージの更新
- IaCテンプレートの構成ミス修正
リポジトリからシークレット文字列を削除するだけでは不十分です。すでに漏えいした可能性がある資格情報は、先に失効またはローテーションしてください。
開発者への通知経路を用意する
推奨事項をDefender for Cloudに表示するだけでは、修復が進まないことがあります。
Azure DevOpsやGitHubではPR注釈を有効化し、開発者がコードレビュー中に問題を確認できるようにします。PR注釈を利用できないGitLabや、PRを経由しない開発フローでは、Logic Apps、GitHub Issues、Azure Boards、ServiceNowなどへの登録を検討します。
通知には、少なくとも次の情報を含めると対応が進みやすくなります。
- リポジトリと対象ファイル
- 検出内容
- 重大度
- 本番環境への到達有無
- 修復手順
- 対応期限
- 担当チーム
- 再検査の方法
監視と自動化を個別推奨事項へ移行する
2026年7月31日より前に、旧推奨事項IDを利用している処理を検索してください。
コードだけでなく、Azure Policy、Logic Apps、KQL、Azure Resource Graph、SIEMのフィルター、外部ツールの設定も対象です。
新旧の推奨事項が同時に表示される期間は、タグやカテゴリーで表示を絞り込みます。新旧両方を無条件でチケット化すると、同じ問題への二重対応が発生しやすくなります。
失敗しやすいポイント
コネクタを作れば全コードが検査されると思い込む
コネクタはインベントリと情報連携の基盤です。コード、シークレット、依存関係、IaCを検査するには、対応するスキャナーやライセンスが必要です。
検出件数だけで安全性を判断する
スキャン対象が狭ければ、検出件数も少なくなります。件数を見る前に、リポジトリ数、ブランチ、スキャナー、ライセンスのカバレッジを確認してください。
Secure Scoreだけを経営指標にする
DevOpsの推奨事項はSecure Scoreへ直接反映されません。DevOpsリスクは、重大度別件数、未解決期間、対象リポジトリ、修復率などで別に管理する必要があります。
個人アカウントを長期間使い続ける
認可アカウントの削除や権限喪失は、インベントリ更新、PR注釈、コードスキャンの停止につながります。専用アカウントと再認可手順を準備してください。
PR注釈がなければ問題がないと判断する
PR注釈は変更差分に関係する問題が中心です。リポジトリ全体の問題はDefender for Cloudの推奨事項でも確認します。
GitHub、Azure DevOps、GitLabを同じ機能範囲で運用する
プラットフォームごとに、必要なライセンス、状態表示、PR注釈、スキャン方式が異なります。共通の運用基準を作りつつ、例外条件を明文化してください。
まとめ
今回のMicrosoft Defender for Cloud DevOps Securityに関する公式情報は、緊急の製品更新というより、複数のDevOps環境を接続し、コードの問題をクラウド側のリスクと関連付け、開発者へ修復を戻す仕組みを明確にしたものです。
管理者が最初に行うべきことは、Defender for Cloudの「環境設定」と「DevOps Security」を開き、コネクタの認可アカウント、対象リポジトリ数、高度なセキュリティ状態、スキャン方式、PR注釈の状態を確認することです。
あわせて、旧推奨事項IDを利用するクエリや自動化がある場合は、2026年7月31日までに個別推奨事項とカテゴリーを使う方式へ移行してください。
コメント