GitHub Advanced Security for Azure DevOps の Security overview は、Azure Repos 全体のセキュリティリスク、スキャンの有効化状況、個別アラートを組織単位で確認するための管理画面です。今回の公式情報で特に重要なのは、リポジトリごとに見に行く運用から、Risk・Coverage・Alerts の3つのタブで横断的に確認し、CSV出力やフィルターURL共有を使って修復を進める運用へ寄せられている点です。管理者はまず、Azure DevOps の Organization settings > Security overview を開き、重大度の高いアラート、スキャン未設定のリポジトリ、90日以上スキャンが止まっている可能性のある領域を確認するのが実務上の第一歩です。(Microsoft Learn)
なお、Microsoft Learn の表示上は英語版の最終更新が 2026年5月26日、日本語版が 2026年5月27日、MicrosoftDocs リポジトリ側では 2026年6月3日にビルド修正が入っています。この記事では、2026年6月4日時点で確認できる公式情報を基準に、管理者・開発者が確認すべき変更点、影響範囲、設定、移行、展開時の注意点を整理します。(Microsoft Learn)
Microsoft Azureのセキュリティ更新で押さえるべきポイント
GitHub Advanced Security for Azure DevOps は、Azure DevOps の Azure Repos に対して、シークレットスキャン、依存関係スキャン、コードスキャン、Security overview などのセキュリティ機能を提供します。GitHub.com 上のリポジトリ向け GitHub Advanced Security とは対象が異なり、今回整理する対象は Azure Repos で管理しているコードです。(Microsoft Learn)
Security overview は、組織全体の状態を次の3つの観点で確認する画面です。
| タブ | 主な役割 | 管理者が見るべきポイント |
|---|---|---|
| Risk | Advanced Security が有効なリポジトリのアラート数と重大度を確認する | Critical / High の未対応アラート、急増したプロジェクト、放置された Dismissed |
| Coverage | 組織内リポジトリの Advanced Security 機能の有効化状況を見る | 未有効のリポジトリ、ツール別の未カバー領域、スキャン停止の疑い |
| Alerts | リポジトリ横断で個別アラートを検索・フィルターする | 優先度順の修復、チームへの共有、CSV出力、キャンペーン化 |
重要なのは、Security overview が「検出結果を見るだけの画面」ではなく、修復対象を絞り、担当チームに渡し、進捗を追うための管理起点になっていることです。
主な変更点：Alertsタブとセキュリティキャンペーンで横断対応しやすくなった
今回の中心となる変更は、Security overview に Alerts タブが追加・整理され、組織内の各リポジトリに分散していた個別アラートを一元的に検索・フィルターできるようになった点です。従来のようにリポジトリ単位で Advanced Security タブを開いて確認するだけでなく、組織全体から「重大度が高い」「特定プロジェクト」「特定ツール」「最近追加された」などの条件で絞り込めます。(Microsoft Learn)
Alerts タブでは、以下のようなフィルターが使えます。
| フィルター | 使いどころ |
|---|---|
| Tool | code scanning、dependency scanning、secret scanning などで絞り込む |
| Severity | critical、high、medium、low など重大度で優先順位を付ける |
| State | open、dismissed、fixed など対応状況で確認する |
| Project | Azure DevOps プロジェクト単位で担当範囲を分ける |
| Repository | 特定リポジトリだけを確認する |
| Time-bound | いつ導入されたアラートかで絞り込む |
さらに、選択したツールに応じて詳細フィルターも変わります。たとえばシークレットでは有効性やシークレット種別、依存関係ではパッケージやエコシステム、コードではツールやルールで絞り込めます。これにより、「全社の Critical を見る」だけでなく、「npm パッケージ由来の高重大度アラート」「特定ルールに該当する CodeQL アラート」「有効なシークレットだけ」といった実務的な切り分けが可能になります。(Microsoft Learn)
セキュリティキャンペーンは“修復作業の単位”として使う
Security campaigns は、フィルター済みのアラートビューをチームに共有し、修復作業を進めるための仕組みです。フィルター条件は URL パラメーターとして保持されるため、たとえば「今スプリントで対応する A プロジェクトの Critical アラート一覧」を URL として共有できます。(Microsoft Learn)
実務では、次のように使うと効果的です。
| 活用シーン | フィルター例 | 進め方 |
|---|---|---|
| スプリント内で重大アラートを潰す | Project = 対象プロジェクト、Severity = Critical / High、State = Open | スプリント計画時に対象URLを共有し、各チームの作業に組み込む |
| シークレット漏えいを優先対応する | Tool = secret scanning、State = Open | まず資格情報を無効化し、再発行と保管場所の見直しまで行う |
| 特定リポジトリ群を集中的に改善する | Repository = 対象リポジトリ、Severity = High以上 | リポジトリオーナーにURLを渡し、期限を決めて対応する |
| CodeQLルール別に横断対応する | Tool = code scanning、Rule = 対象ルール | 共通ライブラリや実装パターンの修正方針を作る |
ポイントは、Alerts タブを「一覧表」として眺めるだけで終わらせないことです。フィルターを修復単位に変換し、担当者・期限・完了条件をセットにすることで、セキュリティ対応が進みやすくなります。
Riskタブで確認すべき影響範囲
Risk タブは、Advanced Security が有効なプロジェクト・リポジトリに対するアラート分布を確認する画面です。報告されるアラート数は、各リポジトリの 既定のブランチで検出されたアラートが対象です。無効化または削除されたリポジトリは結果から除外されます。(Microsoft Learn)
管理者が見るべきポイントは、単純な合計数ではありません。次の順番で確認すると、対応の優先順位を誤りにくくなります。
| 確認項目 | 見る理由 | 判断基準 |
|---|---|---|
| Open の Critical / High | 現在の実リスクが高い | 本番系・外部公開系リポジトリから優先 |
| New の増加 | 最近の変更で新たなリスクが入った可能性がある | 直近スプリントやリリースブランチと照合 |
| Dismissed の理由 | 誤検知処理が妥当か確認する | コメントなし、理由が曖昧なものは再確認 |
| Fixed の推移 | 改善が進んでいるか確認する | チーム単位で改善傾向を見る |
| プロジェクト別偏り | 特定チームにリスクが集中していないか確認する | CI/CD設定や依存関係管理の差を疑う |
Risk タブでは、Open、New、Dismissed、Fixed の列で並べ替えられます。また、検索バーやプロジェクト、ツール、期間フィルターを使って絞り込めます。期間は既定で過去7日間の結果が表示され、フィルター条件は URL パラメーターとして共有できます。(Microsoft Learn)
失敗しやすいポイント：Riskの数値だけで全体安全性を判断しない
Risk タブに表示されるのは、Advanced Security が有効なリポジトリに関する情報です。つまり、Advanced Security が未有効のリポジトリが多い組織では、Risk タブのアラート数が少なく見えても、実際にはスキャン対象外のコードが残っている可能性があります。
そのため、Risk タブを見た後は必ず Coverage タブも確認します。Risk は“検出されたリスク”、Coverage は“検出できる状態にあるか”を見る画面と分けて考えると、運用ミスを防ぎやすくなります。
Coverageタブで確認すべき設定と展開状況
Coverage タブでは、有効化状況に関係なく組織内のリポジトリが表示されます。Advanced Security が有効なリポジトリでは、依存関係スキャン、コードスキャン、シークレットスキャンなど、ツール別の状態も確認できます。無効化・削除済みリポジトリは自動的に除外されます。(Microsoft Learn)
Coverage で特に注意したいのは、有効化表示と継続的なスキャン実行は同じではないという点です。公式情報では、SARIF 結果ファイルが Advanced Security に正常送信されると、依存関係スキャン、コードスキャン、シークレットスキャンのアラートが有効になります。ただし、有効化状態はスキャンの新しさを考慮しません。また、組織またはプロジェクトレベルで Enable all を選択した後、最近の有効化イベントの反映に最大24時間の遅延が発生する可能性があります。(Microsoft Learn)
90日以上スキャンが止まっている可能性に注意する
2026年の更新では、Coverage ペインで 90日を超えて結果を出していないツールが古いスキャンとして識別されるようになっています。これは、パイプライン設定の変更、ジョブの停止、対象ブランチの変更などで、意図せずスキャンが止まっている状態を見つけるために重要です。(Microsoft Learn)
管理者は、Coverage タブで次の観点を確認してください。
| 確認項目 | 実務上の意味 | 対応 |
|---|---|---|
| 未有効のリポジトリ | そもそも検出対象外 | 重要度に応じて Advanced Security を有効化 |
| 特定ツールだけ未カバー | 依存関係・コード・シークレットのいずれかが見えていない | 必要なスキャン設定やパイプラインを追加 |
| 90日超の古いスキャン | CI/CD変更や停止で検出が止まった可能性 | パイプライン履歴、ブランチ、エージェント状態を確認 |
| 新規リポジトリだけ未有効 | 自動有効化設定が漏れている可能性 | 新規リポジトリ・新規プロジェクトの自動有効化を確認 |
| 組織全体の反映遅延 | 直後に状態が合わないことがある | 有効化後すぐに判断せず、最大24時間の遅延を考慮 |
Coverage は、セキュリティ担当だけでなく、Azure DevOps 管理者やプラットフォームチームが定期的に見るべき画面です。特にリポジトリ作成が多い組織では、毎月ではなく週次で確認するほうが運用に合います。
Alertsタブで修復を優先順位付けする
Alerts タブでは、組織全体の個別アラートを一元的に確認できます。ここで大切なのは、すべてのアラートを同じ重みで扱わないことです。
現実的には、次の順番で対応すると効果が出やすくなります。
| 優先度 | 対象 | 理由 |
|---|---|---|
| 最優先 | 有効なシークレット、Critical / High の新規アラート | 悪用可能性や影響が高い |
| 高 | 外部公開サービス、本番デプロイ対象、共通ライブラリ | 影響範囲が広い |
| 中 | 既知脆弱性を含む直接依存関係 | 修正方針を取りやすい |
| 中〜低 | 推移的依存関係、誤検知の可能性が高いコードアラート | 調査と影響確認が必要 |
| 別管理 | Risk accepted / False positive で閉じたもの | 定期レビューで妥当性を確認 |
Alerts タブからは、最大で最初の1,000件までのアラートを CSV にエクスポートできます。エクスポートは現在適用しているフィルターを反映するため、たとえば「Critical の未対応だけ」「特定プロジェクトだけ」といった形で、会議資料やチケット化の元データとして使えます。(Microsoft Learn)
ただし、CSVに出しただけでは改善は進みません。エクスポート後は、次のように処理を決めておくと運用が安定します。
| CSV出力後の処理 | 具体例 |
|---|---|
| チケット化 | Azure Boards、Backlog、Jira などに担当者付きで登録 |
| 重複整理 | 同じ原因のアラートを1つの修正タスクにまとめる |
| 期限設定 | Critical は次回リリース前、High は次スプリント内など |
| 例外管理 | Risk accepted は理由・承認者・再確認日を残す |
| 再確認 | 修正後に再スキャンし、Fixed になったことを確認 |
管理者が確認すべき権限設定
Security overview は組織設定を表示できるメンバーが確認できますが、アラート閲覧、アラートの却下、Advanced Security 設定管理にはそれぞれ権限が関係します。公式情報では、アラート概要を見るにはリポジトリの Contributor 権限、アラートを dismiss するには Project administrator 権限、Advanced Security の権限管理には Project Collection Administrators グループまたは Advanced Security: Manage settings の許可が必要とされています。(Microsoft Learn)
特に注意すべきなのは、Advanced Security: Manage settings です。この権限を持つユーザーは Advanced Security 機能を有効化でき、課金が発生する可能性があります。権限を広く付与しすぎると、意図しないリポジトリ有効化やコスト増につながるため、最小権限で設計するべきです。(Microsoft Learn)
| 役割 | 推奨権限 | 理由 |
|---|---|---|
| 開発者 | Read alerts | 自分のリポジトリのアラートを確認・修正するため |
| テックリード | Read alerts、必要に応じて Manage and dismiss alerts | 誤検知判断や修復方針の決定に関わるため |
| セキュリティ担当 | Read alerts、Manage and dismiss alerts | 横断的なトリアージや例外管理を行うため |
| Azure DevOps 管理者 | Manage settings | 有効化・無効化・課金影響を管理するため |
| 一時参加者・外部委託 | 原則最小限 | リポジトリ横断のアラート可視化を避けるため |
また、2026年のリリースでは、Security overview が Advanced Security: Read alerts 権限を Risk と Coverage の両方で強制する変更も示されています。権限がないリポジトリは Security overview の結果に表示されないため、管理者は「表示されない＝存在しない」と誤解しないように注意が必要です。(Microsoft Learn)
有効化・展開時に確認すべき設定
GitHub Advanced Security for Azure DevOps は、組織、プロジェクト、リポジトリの各レベルで有効化できます。組織・プロジェクト単位の Enable all は既存リポジトリを対象にするため、今後作られるリポジトリやプロジェクトに自動適用したい場合は、別途「新しいリポジトリ」または「新しいプロジェクト」への自動有効化設定を選択する必要があります。(Microsoft Learn)
展開時の確認ポイントは次の通りです。
| 項目 | 確認内容 | 注意点 |
|---|---|---|
| 有効化単位 | 組織、プロジェクト、リポジトリのどこで有効化するか | 一括有効化は課金影響も大きい |
| 新規作成時の自動有効化 | 新規リポジトリ・新規プロジェクトに適用するか | Enable all とは別設定 |
| Secret Protection / Code Security | 必要な製品・機能だけを有効化するか | スタンドアロン構成では製品単位の課金を確認 |
| 依存関係スキャン | 既定セットアップかパイプライン追加か | Advanced Security 有効化だけでは依存関係スキャンは自動実行されない |
| コードスキャン | 既定セットアップか高度なセットアップか | カスタムビルドや複数ブランチは高度なセットアップを検討 |
| シークレットスキャン | プッシュ保護と履歴スキャンの動作を確認 | 有効化後のプッシュと既存履歴で挙動が異なる |
| セルフホステッドエージェント | URL許可リスト、.NET、CodeQLバンドル | ネットワーク制限がある環境では事前確認が必須 |
Secret Protectionの確認ポイント
Secret Protection を有効にすると、シークレットスキャンとプッシュ保護が有効になります。シークレットスキャンは既存履歴を含めて検出し、プッシュ保護は有効化後のプッシュを評価します。漏えいしたシークレットが検出された場合は、コードから消すだけでは不十分です。資格情報を無効化し、新しい資格情報を発行し、安全な保管先に移す必要があります。Azure Key Vault などのシークレット管理ソリューションの利用も選択肢になります。(Microsoft Learn)
よくある失敗は、検出されたキーを削除してコミットし直しただけで完了扱いにすることです。一度リポジトリに入ったシークレットは、履歴や外部コピーに残っている可能性があります。無効化・再発行・利用先更新・履歴確認までを対応手順に含めてください。
Dependency scanningの確認ポイント
依存関係スキャンは、直接依存と推移的依存の脆弱性を検出します。ただし、Advanced Security または Code Security を有効にしただけでは依存関係スキャンは自動実行されません。AdvancedSecurity-Dependency-Scanning@1 タスクを含むパイプラインを実行するか、依存関係スキャンの既定セットアップを有効にする必要があります。(Microsoft Learn)
依存関係スキャンのアラート対応では、直接依存ならバージョン更新、推移的依存ならルート依存関係の更新または限定的な override を検討します。むやみに全体 override を入れると、実行時不具合を招く可能性があるため、依存関係ツリーを確認して対象を絞ることが重要です。(Microsoft Learn)
Code scanningの確認ポイント
コードスキャンは CodeQL を使ってコード上の脆弱性やコーディングエラーを検出します。構成方法には、パイプライン設定が不要な既定セットアップと、CodeQL タスクを Azure Pipelines に追加する高度なセットアップがあります。既定セットアップは導入が速く、標準的なリポジトリに向いています。一方、複数ブランチを対象にしたい、特定のエージェントプールを使いたい、コンパイル言語でカスタムビルド手順が必要、といった場合は高度なセットアップが適しています。(Microsoft Learn)
CodeQL の既定セットアップは組織設定からエージェントプールやスキャンスケジュールを管理できます。セルフホステッドエージェントを使う場合は、CodeQL バンドルや必要なツール、ネットワーク到達性を事前に確認してください。(Microsoft Learn)
課金と移行で注意すべき点
GitHub Advanced Security for Azure DevOps の利用にはライセンスが必要で、Advanced Security が有効なリポジトリに過去90日以内の push に含まれるアクティブコミッターが課金対象の基準になります。課金は Azure DevOps 組織に関連付いた Azure サブスクリプションに対して月次で行われ、日次の利用量に基づいて計上されます。アクティブコミッターは、同じ Azure サブスクリプションに紐づく組織間で重複排除されます。(Microsoft Learn)
特に大規模組織では、組織単位で一括有効化する前に、次の順番で確認してください。
| 確認順 | 内容 |
|---|---|
| 1 | 対象リポジトリの重要度を分類する |
| 2 | 過去90日以内のアクティブコミッター数の見積もりを見る |
| 3 | Secret Protection と Code Security のどちらが必要か整理する |
| 4 | まず重要リポジトリでパイロット導入する |
| 5 | Coverage と Alerts で運用負荷を確認する |
| 6 | 組織・プロジェクト単位の自動有効化を検討する |
既存顧客向けには、現在の Advanced Security 体験に中断はないとされています。Secret Protection と Code Security のスタンドアロン製品へ移行したい場合は、Azure Portal 経由で Azure DevOps サポートにチケットを作成し、問題種別として「Billing migration from bundled to standalone products」を選ぶ必要があります。この移行はサブスクリプション単位で行われ、提供した Azure サブスクリプションに紐づくすべての Azure DevOps 組織が対象になり、不可逆とされています。(Microsoft Learn)
そのため、移行を検討する場合は、単に「安くなりそうか」だけで判断せず、次の点を事前に整理してください。
- 対象 Azure サブスクリプションに紐づく Azure DevOps 組織の一覧
- 各組織で有効化済みのリポジトリ数
- Secret Protection と Code Security の利用対象
- 請求部門・プロジェクト部門への費用配賦ルール
- 移行後に戻せないことへの承認フロー
Pull Request運用との接続も見直す
Security overview は組織全体の可視化に役立ちますが、開発現場でリスクを減らすには Pull Request 時点での制御も重要です。Advanced Security では、依存関係スキャン、コードスキャン、シークレットスキャンの結果を評価し、脆弱性が検出された場合に Pull Request のマージを防ぐステータスチェックを使えます。公式情報では、すべての重大・高重大度アラートをブロックする AdvancedSecurity/AllHighAndCritical と、新規の重大・高重大度アラートをブロックする AdvancedSecurity/NewHighAndCritical が示されています。(Microsoft Learn)
現実的には、既存アラートが多い組織でいきなり AllHighAndCritical を必須化すると、開発が止まりやすくなります。まずは NewHighAndCritical を使い、「新しい重大リスクを増やさない」方針から始めると導入しやすくなります。
| 状況 | 推奨する始め方 |
|---|---|
| 既存アラートが多い | NewHighAndCritical で新規混入を防ぐ |
| 重要リポジトリだけ厳格にしたい | 本番系ブランチに AllHighAndCritical を適用 |
| 開発速度を優先したい | まずアラート通知と Security campaign で運用 |
| 規制・監査要件がある | 例外承認、Dismiss理由、監査ログをセットで管理 |
監査ログとCSV出力でガバナンスを強化する
2026年のリリースでは、Advanced Security の有効化設定が変更されたときに Azure DevOps の監査ログにイベントが記録される更新も示されています。監査ログには、誰が、いつ、どの設定を変更したかが含まれ、対象には Advanced Security、Code Security / Secret Protection、CodeQL 既定セットアップ、依存関係スキャン既定セットアップ、シークレットプッシュ保護などが含まれます。(Microsoft Learn)
管理者は、次のような運用ルールを作っておくとよいでしょう。
| 管理対象 | 推奨ルール |
|---|---|
| Advanced Security の有効化・無効化 | 変更前に申請またはチケットを残す |
| Dismissed アラート | 理由、承認者、再確認日を必須にする |
| CSVエクスポート | 個人情報や機密情報の取り扱いルールに従う |
| Security campaign URL | 閲覧権限のあるメンバーに限定して共有 |
| 監査ログ | 月次またはリリース前に変更履歴を確認 |
特に、Security overview の CSV はセキュリティ上の弱点やリポジトリ名を含む可能性があります。社外共有や広範なメール添付は避け、アクセス制御された場所に保管するのが安全です。
管理者・開発者向けの実務チェックリスト
最後に、今回の公式情報を踏まえて、すぐ確認すべき項目をチェックリストにまとめます。
| 対象者 | 確認すべきこと | 完了の目安 |
|---|---|---|
| Azure DevOps 管理者 | Organization settings > Security overview を開けるか | Risk / Coverage / Alerts が確認できる |
| セキュリティ管理者 | Critical / High の Open アラートを抽出する | Security campaign URL を担当チームに共有済み |
| プロジェクト管理者 | Coverage で未有効・古いスキャンを確認する | 重要リポジトリの未カバーがない |
| 開発リード | PR時のステータスチェック方針を決める | NewHighAndCritical などの適用方針がある |
| 開発者 | 自分の担当アラートの修正方法を確認する | 修正後に再スキャンし Fixed を確認 |
| 情シス・管理部門 | 課金対象のアクティブコミッターを確認する | 有効化範囲と費用配賦が説明できる |
| 監査担当 | 有効化変更と Dismissed の履歴を確認する | 例外理由と承認履歴が残っている |
Security overview は、Azure Repos のセキュリティ状態を“見える化”するだけでなく、チーム横断で修復を進めるための起点です。まずは Risk で重大度の高いアラートを把握し、Coverage でスキャン対象外や停止状態を潰し、Alerts で担当チームごとの修復キャンペーンを作成してください。大規模展開の前には、権限、課金、既定セットアップ、PRステータスチェック、移行方針を確認し、重要リポジトリから段階的に展開するのが安全です。
コメント