Azure ReposでGitHub Advanced Security for Azure DevOpsを設定する際の結論は、Secret ProtectionとCode Securityを必要な範囲に分けて有効化し、課金・権限・パイプライン影響を確認してから段階展開することです。特に管理者は、「すべて有効にする」が既存リポジトリだけに作用する点、新規リポジトリへの自動適用は別設定である点、CodeQLや依存関係スキャンはパイプライン設計に影響する点を見落とさないようにする必要があります。
2026年5月27日に更新されたMicrosoft Learnの公式情報では、GitHub Advanced Security for Azure DevOpsの構成対象、Secret ProtectionとCode Securityの機能差、Azure Reposでの有効化単位、プルリクエスト注釈や状態チェックまで整理されています。この記事では、Microsoft Azure環境でAzure DevOpsを管理する担当者向けに、変更点・影響範囲・設定確認・移行時の注意点を実務目線でまとめます。(Microsoft Learn)
今回の要点：Azure Reposの保護機能を「秘密情報」と「コード品質・依存関係」に分けて考える
GitHub Advanced Security for Azure DevOpsは、Azure Reposに対してGitHub Advanced Securityのセキュリティ機能を追加する仕組みです。主な機能は、シークレットスキャンのプッシュ保護、リポジトリ内のシークレットスキャン、依存関係スキャン、CodeQLによるコードスキャンです。公式情報では、これらが大きくGitHub Secret Protection for Azure DevOpsとGitHub Code Security for Azure DevOpsに整理されています。(Microsoft Learn)
| 区分 | 主な機能 | 実務上の意味 | 優先して有効化したいリポジトリ |
|---|---|---|---|
| Secret Protection | プッシュ保護、シークレットスキャンアラート、Security overview | APIキー、接続文字列、資格情報などの漏えいを防ぐ | すべてのアクティブなリポジトリ、IaC、デプロイスクリプト、運用手順を含むリポジトリ |
| Code Security | 依存関係アラート、CodeQLスキャン、サードパーティツールの検出結果、Security overview | OSS脆弱性やコードレベルの脆弱性を早期に検出する | 外部公開サービス、顧客データを扱うアプリ、CI/CDが整備された主要リポジトリ |
重要なのは、「セキュリティ機能を一括で入れるかどうか」ではなく、リポジトリごとにどのリスクを先に下げるかを決めることです。迷う場合は、まずSecret Protectionを広く検討し、Code Securityはビルド時間・パイプライン構成・修正体制を確認しながら主要リポジトリから展開すると失敗しにくくなります。
影響範囲：対象はAzure DevOps ServicesのAzure Repos Gitリポジトリ
GitHub Advanced Security for Azure DevOpsは、Azure DevOps Servicesで利用でき、対象はコード用のGitリポジトリです。GitHubリポジトリでGitHub Advanced Securityを使う場合は別のGitHub側の機能として扱う必要があります。(Microsoft Learn)
そのため、影響範囲の確認では次の切り分けが必要です。
| 確認対象 | 確認ポイント | 対応の考え方 |
|---|---|---|
| Azure DevOps組織 | Azure Reposを利用しているか | GitHub側リポジトリと混同しない |
| リポジトリ種別 | コード用のGitリポジトリか | Git以外の資産は別の管理方法を検討する |
| プロジェクト | 一括有効化の対象にするか | 課金見積もりとリポジトリ所有者を確認する |
| 新規リポジトリ | 今後作成されるリポジトリにも自動適用するか | 「すべて有効」とは別に自動有効化を設定する |
| パイプライン | Azure Pipelinesでスキャンを実行できるか | Code Securityではビルド時間やエージェント要件を確認する |
開発者への影響も小さくありません。Secret Protectionのプッシュ保護が有効になると、シークレットを含む今後のプッシュはブロックされます。また、依存関係スキャンやコードスキャンをプルリクエストに組み込むと、レビュー時に脆弱性の指摘や状態チェックが表示されるようになります。(Microsoft Learn)
有効化レベルの選び方：組織・プロジェクト・リポジトリのどこで管理するか
Advanced Security、Secret Protection、Code Securityは、組織、プロジェクト、リポジトリの各レベルで有効化できます。管理画面の「すべて有効にする」は既存リポジトリに対する操作であり、新しく作成されるリポジトリやプロジェクトへ自動適用したい場合は、別途自動有効化の設定を選ぶ必要があります。(Microsoft Learn)
| 有効化レベル | 向いているケース | 注意点 |
|---|---|---|
| リポジトリ単位 | まず検証したい、重要リポジトリだけ先行したい | リポジトリ数が多いと運用が手作業になりやすい |
| プロジェクト単位 | チームやサービス単位でまとめて管理したい | 既存リポジトリと新規リポジトリの扱いを分けて確認する |
| 組織単位 | 全社標準として展開したい | 課金、権限、アラート運用の設計を先に固める必要がある |
実務では、最初から組織全体にCode Securityを展開するより、次の順序が現実的です。
| フェーズ | 対象 | 目的 |
|---|---|---|
| 検証 | 代表的な1〜3リポジトリ | アラート量、ビルド時間、開発者への影響を確認する |
| 先行展開 | 外部公開アプリ、重要API、顧客データを扱うリポジトリ | 重大リスクを優先して下げる |
| 標準化 | プロジェクトまたは組織全体 | 新規リポジトリへの自動適用と運用ルールを整える |
管理者が最初に確認すべき権限設定
Advanced Security関連の権限は、単なる閲覧権限ではありません。特に「設定の管理」は、機能の有効化や無効化に関わり、課金が発生する可能性がある操作です。公式情報では、アラート閲覧、アラート管理・無視、設定管理の3種類の権限が整理されています。(Microsoft Learn)
| 権限 | できること | 付与すべき相手 |
|---|---|---|
| Advanced Security: アラートの読み取り | 脆弱性やスキャン結果を確認する | 開発者、セキュリティ担当、レビュアー |
| Advanced Security: アラートを管理および無視する | 誤検知の無視、アラートライフサイクル管理 | セキュリティエンジニア、リード開発者 |
| Advanced Security: 設定を管理する | 機能の有効化・無効化 | Azure DevOps管理者、セキュリティ管理者など少数 |
よくある失敗は、プロジェクト管理者に広く権限を与えた結果、検証前のリポジトリまで有効化され、想定外の課金や大量アラートが発生するケースです。設定管理権限は最小限にし、リポジトリ所有者には原則としてアラート閲覧またはアラート管理までを付与する設計が安全です。
API連携でAdvanced Securityの情報を取得する場合は、個人用アクセストークンよりもMicrosoft Entra IDトークンの利用が推奨されています。条件付きアクセスや多要素認証、監査との整合性を考えると、運用スクリプトやダッシュボード連携もEntra IDベースに寄せるのが望ましい設計です。(Microsoft Learn)
課金で確認すべきポイント：アクティブコミッター数を見積もる
Advanced Securityの機能を利用するにはライセンスが必要です。課金の考え方では、対象リポジトリに対する過去90日以内のプッシュに含まれるコミッターがアクティブコミッターとして扱われます。Secret ProtectionとCode Securityは、Azure DevOps組織に関連付けられたAzureサブスクリプションへ課金され、製品ごとのアクティブコミッター数が重要になります。(Microsoft Learn)
| 確認項目 | 見るべき場所・考え方 |
|---|---|
| 有効化前の見積もり | 組織、プロジェクト、リポジトリで有効化する前に表示されるアクティブコミッター数を確認 |
| 実際の使用数 | Organization settings > Billingで前日測定の使用済みライセンス数を確認 |
| 重複カウント | 同一Azureサブスクリプション、同一製品に紐づく場合はアクティブコミッターが重複除去される |
| 予算管理 | Secret ProtectionとCode Securityを別々に有効化する場合、製品ごとの対象リポジトリを棚卸しする |
既存顧客がスタンドアロンのSecret ProtectionとCode Securityへ移行する場合、既存のAdvanced Security体験は中断されないとされています。ただし、移行はAzure PortalからAzure DevOpsサポートにチケットを出す形で行い、Azureサブスクリプション単位で実施されます。提供したサブスクリプションに紐づく組織が対象になり、この要求は元に戻せないため、事前に対象サブスクリプションと組織の対応表を作っておくべきです。(Microsoft Learn)
Secret Protectionの設定ポイント：まず「漏えいを止める」運用を作る
Secret Protectionを有効にすると、シークレットスキャンのプッシュ保護とリポジトリスキャンが自動的に有効になります。プッシュ保護は有効化後のプッシュを評価し、リポジトリレベルのシークレットスキャンは履歴コミットを含む既存シークレットを検出してアラートを生成します。(Microsoft Learn)
管理者が準備すべきなのは、設定そのものよりも検出後の運用です。
| 場面 | 開発者が取るべき対応 | 管理者が整備すべきルール |
|---|---|---|
| プッシュがブロックされた | コミットからシークレットを除去し、コード外の安全な保管先に移す | どこに保管するか、誰に相談するかを明文化する |
| 履歴コミットから検出された | 影響範囲を確認し、必要に応じて資格情報をローテーションする | インシデント扱いにする基準を決める |
| 誤検知の疑いがある | すぐに無視せず、リード開発者またはセキュリティ担当に確認する | アラートを無視できる権限者を限定する |
よくある失敗は、プッシュ保護を有効にしただけで安心してしまうことです。プッシュ保護は今後の混入を止める仕組みであり、過去のコミットに含まれる秘密情報の影響を消すものではありません。履歴スキャンの初回アラートは、単なるノイズとして扱わず、認証情報の有効性、外部公開リポジトリかどうか、利用先システムの重要度で優先順位を付けて対応します。
Dependency Scanningの設定ポイント：パッケージ復元後に実行する
依存関係スキャンを使うには、対象リポジトリでCode Securityを有効にする必要があります。依存関係スキャンはパイプラインベースのスキャンで、既定ブランチを対象にする場合はリポジトリ設定から「脆弱性のある依存関係をスキャンする」を利用できます。より高度な設定や全ブランチを対象にする場合は、スキャンしたいパイプラインに依存関係スキャンタスクを追加します。(Microsoft Learn)
実務で重要なのは、タスクの置き場所です。公式のトラブルシューティングでは、最も正確な結果を得るには、ビルドステップまたはパッケージ復元ステップの後に依存関係スキャンタスクを追加することが示されています。復元前に実行すると、コンポーネントをうまく識別できず、既知の脆弱性がある依存関係でもアラートが出ない可能性があります。(Microsoft Learn)
| 失敗例 | 原因 | 対応 |
|---|---|---|
| 依存関係が検出されない | npm installやdotnet restoreなどの復元前にスキャンしている | パッケージ復元後にAdvancedSecurity-Dependency-Scanning@1を配置する |
| 大規模リポジトリでタイムアウトする | 既定の実行時間内に終わらない | DependencyScanning.Timeoutで秒数を増やす |
| モノレポで不要な範囲までスキャンされる | 既定ではAgent.BuildDirectoryが処理対象 | DependencyScanning.SourcePathで対象ディレクトリを指定する |
| 結果が別リポジトリに出る | パイプライン定義とスキャン対象コードが別リポジトリ | advancedsecurity.publish.repository.infer: trueを設定する |
特にモノレポや複数リポジトリを参照するパイプラインでは、スキャン結果がどのリポジトリに紐づくかを必ず検証してください。アラートが表示されない場合、脆弱性がないのではなく、結果の公開先やスキャン対象パスがずれているだけというケースがあります。(Microsoft Learn)
Code Scanningの設定ポイント：既定のセットアップと詳細設定を使い分ける
コードスキャンではCodeQLを使ってAzure DevOpsリポジトリ内のコードを分析し、セキュリティ脆弱性やコーディングエラーをアラートとして表示します。利用にはGitHub Advanced Security for Azure DevOps、またはスタンドアロン利用時のGitHub Code Securityが必要です。(Microsoft Learn)
コードスキャンには、既定のセットアップと詳細設定があります。
| 項目 | 既定のセットアップ | 詳細設定 |
|---|---|---|
| パイプライン変更 | 不要 | CodeQLタスクを手動追加 |
| 言語検出 | CodeQL対応言語を自動検出 | タスクで言語を指定 |
| ブランチ範囲 | 既定ブランチ中心 | パイプラインをトリガーするブランチ |
| ビルド制御 | カスタムビルドステップなし | コンパイル済み言語のビルド手順を制御 |
| 向いているケース | 早く有効化したい、標準的にスキャンしたい | 複数ブランチ、カスタムエージェント、既存CI/CD統合が必要 |
多くのリポジトリでは、まず既定のセットアップから開始し、必要に応じて詳細設定へ切り替えるのが安全です。既定のセットアップでは、組織設定からエージェントプールやスキャンスケジュールを構成できます。Microsoftホステッドエージェント、セルフホステッドエージェント、Managed DevOps Poolsの選択も検討対象になります。(Microsoft Learn)
詳細設定では、CodeQLタスクをAzure Pipelinesに直接追加します。コードスキャンは時間のかかるビルドタスクになる可能性があるため、メインの本番パイプラインにそのまま入れるより、複製した別パイプラインや新規パイプラインで実行する設計が推奨されています。(Microsoft Learn)
steps:
- task: AdvancedSecurity-Codeql-Init@1
inputs:
languages: "javascript"
enableAutomaticCodeQLInstall: true
# ここにビルドやテストのステップを配置する
- task: AdvancedSecurity-Dependency-Scanning@1
- task: AdvancedSecurity-Codeql-Analyze@1CodeQLの詳細設定では、AdvancedSecurity-Codeql-Init@1、カスタムビルドステップ、AdvancedSecurity-Codeql-Analyze@1の順序が基本です。対応言語には、C/C++、C#、Go、Java/Kotlin、JavaScript/TypeScript、Python、Ruby、Swiftが含まれます。JavaとKotlinはjava、JavaScriptとTypeScriptはjavascriptとして扱う点も押さえておきましょう。(Microsoft Learn)
セルフホステッドエージェント利用時の注意点
セルフホステッドエージェントを使っている組織では、ネットワークとランタイムの前提条件を先に確認します。依存関係スキャンが脆弱性アドバイザリデータを取得できるよう、dev.azure.com、advsec.dev.azure.com、governance.dev.azure.comなどのURLを許可リストに追加する必要があります。また、2026年4月時点では互換性のある.NETランタイムとして.NET 8.xが示されており、CodeQLバンドルのインストールまたは自動インストール設定も確認が必要です。(Microsoft Learn)
セルフホステッドエージェントで失敗しやすいのは、Azure DevOpsの設定画面では有効化できているのに、パイプライン実行時に外部接続やCodeQL取得で止まるケースです。展開前に、代表リポジトリで以下を確認してください。
| 確認項目 | 見落とすと起きること |
|---|---|
| 許可リスト | 脆弱性データ取得や結果送信に失敗する |
| .NETランタイム | 依存関係スキャンタスクの実行に時間がかかる、または失敗する |
| CodeQLバンドル | CodeQL初期化に失敗する |
| エージェントプールの余力 | スキャン待ちでCI/CD全体が遅延する |
| ビルドツール | コンパイル済み言語で正しい解析結果が出ない |
プルリクエスト注釈と状態チェックは「開発フロー変更」として扱う
依存関係スキャンとコードスキャンのプルリクエスト注釈は、スキャンタスクを含むパイプラインにビルド検証ポリシーが適用されている場合に自動構成されます。また、PRブランチをスキャンする前に、既定ブランチとターゲットブランチのAdvanced Securityスキャンが必要です。(Microsoft Learn)
さらに、Advanced Securityの状態チェックを使うと、セキュリティ脆弱性が検出されたプルリクエストのマージをブロックできます。利用できる状態チェックには、すべての重大・高重大度アラートの解決を求めるAdvancedSecurity/AllHighAndCriticalと、新規の重大・高重大度脆弱性をブロックするAdvancedSecurity/NewHighAndCriticalがあります。(Microsoft Learn)
実務では、いきなりAllHighAndCriticalを必須にすると、既存アラートが多いリポジトリでは開発が止まる可能性があります。初期導入では、まずアラートを可視化し、修正期限と例外承認ルールを作ったうえで、次にNewHighAndCriticalで新規混入を防ぐ流れが現実的です。
移行・展開前のチェックリスト
展開前には、機能の有効化だけでなく、運用面の準備を確認します。
| チェック項目 | 管理者が確認すること | 開発者に共有すること |
|---|---|---|
| 対象リポジトリ | 重要度、所有者、アクティブコミッター数 | いつから有効化されるか |
| 製品選択 | Secret Protectionのみか、Code Securityも有効にするか | どのアラートが出る可能性があるか |
| 権限 | 設定管理権限を誰に付与するか | アラート確認・対応の担当範囲 |
| パイプライン | 依存関係復元、ビルド、CodeQL順序、エージェント | ビルド時間が変わる可能性 |
| PRポリシー | 注釈だけにするか、状態チェックでブロックするか | マージ条件が変わる可能性 |
| 課金 | Azureサブスクリプション、製品別アクティブコミッター数 | 対象範囲拡大時の承認フロー |
| 例外運用 | 誤検知、緊急リリース、未修正アラートの扱い | 例外申請の方法 |
特に移行では、既存のバンドル型Advanced SecurityからSecret ProtectionとCode Securityのスタンドアロン製品へ移る場合、対象Azureサブスクリプションに紐づく全組織へ影響する点を確認してください。サポートチケットを出す前に、Azureサブスクリプション、Azure DevOps組織、対象プロジェクト、利用中リポジトリ、現在の課金状況を一覧化しておくと、移行後の想定違いを防げます。(Microsoft Learn)
展開手順：小さく始めて、標準設定として広げる
おすすめの展開手順は次の通りです。
| 手順 | 実施内容 | 完了条件 |
|---|---|---|
| 事前棚卸し | Azure Reposのリポジトリ、所有者、主要言語、CI/CD有無を整理 | 対象一覧と優先度が決まっている |
| 権限設計 | 設定管理、アラート管理、閲覧権限を役割別に整理 | 課金操作ができる人を限定できている |
| パイロット | 代表リポジトリでSecret ProtectionとCode Securityを検証 | アラート量、ビルド時間、PR表示を確認済み |
| 本番展開 | プロジェクト単位または組織単位で展開 | 新規リポジトリ自動有効化の要否も設定済み |
| 運用定着 | アラートのトリアージ、修正期限、例外承認を運用 | セキュリティアラートが放置されない |
初回導入時は、アラートが大量に出ること自体を失敗と見なさないことが大切です。むしろ、これまで見えていなかったシークレット、古い依存関係、危険なコードパターンが可視化された状態です。重要なのは、すべてを即日修正しようとすることではなく、重大度、外部公開有無、悪用可能性、修正コストで優先順位を付けることです。
失敗しやすいポイントと回避策
| 失敗しやすいポイント | 何が起きるか | 回避策 |
|---|---|---|
| 「すべて有効」で新規リポジトリも対象になると思い込む | 新規リポジトリだけ保護されない | 自動有効化設定を別途確認する |
| 設定管理権限を広く付与する | 意図しない有効化や課金が発生する | 設定管理は少人数に限定する |
| Code Securityを有効にしただけでスキャン完了と思う | パイプライン未設定で結果が出ない | 既定セットアップまたは詳細設定を確認する |
| 依存関係復元前にスキャンする | 依存関係を検出できない | 復元・ビルド後にスキャンタスクを置く |
| PR状態チェックを最初から厳しくする | 既存アラートでマージが止まる | 初期は可視化、次に新規高重大度のブロックへ移行する |
| セルフホステッドエージェントの通信要件を確認しない | スキャンやCodeQL取得が失敗する | URL許可リスト、.NET、CodeQLバンドルを事前確認する |
| スキャン結果の公開先を検証しない | 別リポジトリに結果が出る | advancedsecurity.publish.repository.inferを検討する |
まとめ：次にやるべきこと
GitHub Advanced Security for Azure DevOpsの設定では、単に機能をオンにするだけでなく、どのリポジトリに、どの製品を、どの権限と課金管理で、どのパイプラインに組み込むかを決める必要があります。
まずはAzure Reposのリポジトリ一覧を作り、Secret Protectionを広く適用する候補と、Code Securityを優先すべき重要リポジトリを分けてください。次に、設定管理権限を絞り、アクティブコミッター数と課金見積もりを確認します。そのうえで、代表リポジトリに対してシークレットスキャン、依存関係スキャン、CodeQLスキャン、PR注釈、状態チェックを順番に検証すると、開発を止めずにAzure DevOpsのセキュリティ水準を引き上げられます。
コメント