GitHub Advanced Security for Azure DevOpsのcode scanningをAzure Reposで使うなら、まず確認すべき結論は「多くのリポジトリはdefault setupから始め、ビルド制御・複数ブランチ・自社エージェント・カスタムクエリが必要なリポジトリだけadvanced setupにする」という点です。code scanningはCodeQLでAzure Repos内のコードを解析し、脆弱性やコーディングエラーをアラートとして可視化します。Microsoft Learnの「Set up code scanning for GitHub Advanced Security for Azure DevOps – Azure Repos」では、default setupとadvanced setupの使い分け、権限、エージェント、スキャン結果の扱いが整理されています。(Microsoft Learn)
本記事では、2026年5月時点の公式情報をもとに、GitHub Advanced Securityのcode scanning設定で管理者・開発者が確認すべき変更点、影響範囲、移行・展開時の注意点を実務向けに整理します。
GitHub Advanced Securityのcode scanningとは
GitHub Advanced Security for Azure DevOpsのcode scanningは、Azure Reposのコードを静的解析し、SQLインジェクションや認証回避などのアプリケーション脆弱性につながる問題を検出する機能です。解析エンジンにはGitHubが開発するCodeQLが使われ、検出結果はAzure DevOpsのRepos配下にあるAdvanced Securityタブで確認できます。(Microsoft Learn)
対象はAzure DevOps ServicesのAzure Repos Gitリポジトリです。GitHub上のリポジトリに対してGitHub Advanced Securityを使う場合は、Azure DevOps向けの設定ではなく、GitHub側のドキュメントと機能を参照する必要があります。(Microsoft Learn)
実務上は、次のような目的で使います。
- リポジトリに潜むセキュリティ上の弱点を早期に見つける
- pull request段階で新しい脆弱性の混入に気づく
- 重要度の高いアラートを開発チームとセキュリティチームで継続的に管理する
- 手作業のコードレビューだけでは見落としやすいパターンを機械的に検出する
ただし、code scanningは「一度有効化すれば終わり」の機能ではありません。どのブランチを対象にするか、どのエージェントで実行するか、検出結果を誰が確認・却下できるかまで決めておかないと、スキャンが動いていても運用に乗らないケースがあります。
2026年5月時点で押さえるべき主な整理ポイント
今回の公式情報で実務上重要なのは、code scanningの導入方法がdefault setupとadvanced setupの2系統として明確に整理されている点です。default setupはパイプライン設定なしで素早く始める方法、advanced setupはAzure PipelinesにCodeQLタスクを追加して細かく制御する方法です。(Microsoft Learn)
| 確認ポイント | 実務上の意味 |
|---|---|
| default setupが推奨の開始点 | 多くの標準的なリポジトリでは、まず自動設定でカバレッジを広げやすい |
| advanced setupは制御重視 | 複数ブランチ、独自ビルド、特定エージェント、カスタムクエリが必要な場合に向く |
| default setupのエージェントとスケジュールを組織設定で管理 | 組織全体の実行負荷やスキャン頻度を管理者側で設計しやすい |
| Code Securityの有効化が前提 | code scanningを使うには、対象リポジトリでGitHub Advanced SecurityまたはCode Security相当の機能を有効にする必要がある |
| アラート管理には権限設計が必要 | 閲覧、却下、設定変更の権限が異なるため、導入前にロール整理が必要 |
特に注意したいのは、default setupが「万能な簡易設定」ではないことです。default setupはすばやく始めるには便利ですが、既定ブランチ中心の運用になります。リリースブランチ、長期保守ブランチ、製品別ブランチも継続的に見る必要がある組織では、advanced setupの検討が必要です。(Microsoft Learn)
影響範囲：対象になる環境とならない環境
code scanningの影響範囲は、Azure DevOpsを使っているすべてのチームに一律で及ぶわけではありません。まず、対象サービス、リポジトリ種別、権限、利用製品を切り分けて確認します。
| 項目 | 確認内容 |
|---|---|
| 対象サービス | Azure DevOps Services |
| 対象リポジトリ | Azure ReposのGitリポジトリ |
| 主な対象者 | Azure DevOps管理者、プロジェクト管理者、リポジトリ管理者、開発者、セキュリティ担当者 |
| 必要な製品・機能 | GitHub Advanced Security for Azure DevOps、またはGitHub Code Security for Azure DevOps |
| GitHubリポジトリ | Azure Repos向け設定ではなく、GitHub側のGitHub Advanced Security設定を使う |
| TFVCやオンプレミス環境 | 公式情報上、Azure DevOps ServicesのGitリポジトリ向けとして扱われているため、適用対象として前提にしない |
GitHub Advanced Security for Azure DevOpsは、Secret ProtectionとCode Securityという製品構成でも説明されています。code scanningやdependency scanningを使うにはCode Securityが関係します。組織・プロジェクト・リポジトリ単位で有効化でき、新規リポジトリや新規プロジェクトへ自動適用する設定は、既存リポジトリへの一括有効化とは別に選択する必要があります。(Microsoft Learn)
default setupとadvanced setupの選び方
code scanningの設定方法は、最初にここで判断します。迷った場合は、標準的なWebアプリや小〜中規模のサービスリポジトリではdefault setupから始め、制約が出たリポジトリだけadvanced setupへ切り替えるのが現実的です。
| 比較項目 | default setup | advanced setup |
|---|---|---|
| 設定方法 | 自動構成。パイプライン変更は不要 | Azure PipelinesにCodeQLタスクを手動追加 |
| 言語検出 | CodeQL対応言語を自動検出 | タスク内で対象言語を指定 |
| 対象ブランチ | 主に既定ブランチ | パイプラインのトリガーに応じて任意のブランチを対象化しやすい |
| ビルド制御 | カスタムビルド手順なし | コンパイル言語のビルド手順を細かく制御可能 |
| エージェント | 組織設定で選択 | パイプライン設計に応じて選択 |
| 向いているケース | まず全体に展開したい、標準的な解析でよい | 複数ブランチ、独自ビルド、重い解析、自社ネットワーク接続、カスタムクエリが必要 |
公式情報でも、default setupは最も素早くcode scanningを有効化できる方法として説明されています。一方、advanced setupは、特定のエージェントプール、コンパイル言語のカスタムビルド、既定ブランチ以外のスキャン、既存CI/CDへの統合、特定のCodeQLクエリスイートやカスタムクエリを使いたい場合に適しています。(Microsoft Learn)
default setupを選ぶべきケース
default setupは、次の条件に当てはまるリポジトリに向いています。
- まずcode scanningを短期間で展開したい
- 既定ブランチの定期スキャンから始めたい
- パイプラインYAMLを変更したくない
- 言語構成が比較的シンプル
- セキュリティ施策の初期導入として、全社的にカバレッジを広げたい
たとえば、JavaScript/TypeScriptやPython中心の社内Webアプリで、既定ブランチに統合してからリリースする運用なら、default setupから始める価値があります。管理者は組織設定でCodeQL default setupのエージェントプールとスキャンスケジュールを確認し、実行負荷が高すぎないかを見ます。
advanced setupを選ぶべきケース
advanced setupは、次のようなリポジトリで検討します。
- main以外のreleaseブランチやhotfixブランチも継続的にスキャンしたい
- C#、Java、C/C++、Swiftなどでビルド手順を厳密に指定したい
- private network内の依存関係や社内パッケージにアクセスする必要がある
- Microsoft-hosted agentでは時間や性能が足りない
- カスタムCodeQLクエリや特定のクエリスイートを使いたい
- 既存のCI/CDパイプラインにセキュリティチェックを組み込みたい
コンパイル言語では、CodeQLが正しくコードの構造を把握できるように、初期化タスクと解析タスクの間に適切なビルド手順を置く必要があります。ビルドキャッシュ、増分ビルド、分散ビルドが解析に影響する場合もあるため、スキャン用パイプラインではクリーンビルドを意識した設計が重要です。(Microsoft Learn)
管理者が確認すべき設定
Code SecurityまたはAdvanced Securityが有効か
code scanningを使う前に、対象リポジトリでGitHub Advanced SecurityまたはCode Securityが有効になっているか確認します。Azure DevOpsでは、組織・プロジェクト・リポジトリ単位で有効化できますが、既存リポジトリへの有効化と今後作成されるリポジトリへの自動有効化は別設定です。(Microsoft Learn)
展開時は、いきなり全社一括ではなく、次の順に進めると失敗しにくくなります。
| フェーズ | 対象 | 目的 |
|---|---|---|
| パイロット | 代表的な1〜3リポジトリ | 実行時間、アラート量、開発者の対応負荷を確認 |
| 部門展開 | 同じ技術スタックの複数リポジトリ | default setupで横展開できるか検証 |
| 全体展開 | 重要度の高いリポジトリから順次 | ブランチポリシーやアラート対応フローを標準化 |
| 継続運用 | 新規リポジトリ含む全体 | 自動有効化、定期レビュー、例外管理を運用化 |
特に請求に関係する設定を扱うため、誰でも有効化できる状態にしないことが重要です。設定変更権限は、プロジェクト管理者やセキュリティ管理者など、責任範囲が明確なユーザーに限定しましょう。
権限設計を見直す
Advanced Securityでは、アラート閲覧、アラート却下、設定管理で必要な権限が異なります。公式情報では、リポジトリのアラート概要を見るにはContributor権限、アラートを却下するにはProject administrator権限、設定を管理するにはProject Collection AdministratorsグループまたはAdvanced Securityのmanage settings権限が必要とされています。(Microsoft Learn)
| 作業 | 必要な権限の考え方 | 注意点 |
|---|---|---|
| アラートを見る | 開発者・セキュリティ担当に読取権限を付与 | 見えないと修正が進まない |
| アラートを却下する | 管理者または承認された担当者に限定 | 誤って「False positive」にすると脆弱性が放置される |
| 設定を変更する | 請求や全体運用に関わるため限定 | manage settingsは慎重に付与 |
| API連携する | Microsoft Entra IDトークンを優先検討 | PAT利用は最小限にする |
権限設計でよくある失敗は、「開発者がアラートを見られない」または「誰でもアラートを閉じられる」のどちらかです。前者は修正が進まず、後者はリスク承認の統制が崩れます。最低限、閲覧は広め、却下と設定変更は狭める方針にすると運用しやすくなります。
default setupのエージェントプールとスケジュールを確認する
default setupでは、組織設定からCodeQL default setupのエージェントプールとスキャンスケジュールを管理します。エージェントプールはAzure Pipelines、self-hosted agent pools、Managed DevOps Poolsから選べます。Microsoft-hosted agentを使うAzure Pipelinesのプールではパイプラインの同時実行枠を消費する点に注意が必要です。(Microsoft Learn)
選定の目安は次の通りです。
| 選択肢 | 向いているケース | 注意点 |
|---|---|---|
| Azure Pipelines | すぐに始めたい、標準的な環境で足りる | パイプライン同時実行数を消費する |
| Self-hosted agent pools | 社内ネットワーク、独自ビルドツール、重い解析が必要 | CodeQLや必要ランタイムの準備が必要 |
| Managed DevOps Pools | 管理されたAzureベースのプールを使いたい | VMイメージや運用ポリシーの確認が必要 |
スキャンスケジュールは週次で設定できます。重要リポジトリでは、default setupの週次スキャンだけで十分か、pull request時にもadvanced setupやブランチポリシーで補完すべきかを判断しましょう。
開発者が確認すべきpipeline設定
advanced setupでは、Azure PipelinesにCodeQLのタスクを追加します。基本の順序は、AdvancedSecurity-Codeql-Init@1で初期化し、必要なビルド手順を実行し、最後にAdvancedSecurity-Codeql-Analyze@1で解析する流れです。(Microsoft Learn)
trigger:
- main
pool:
vmImage: ubuntu-latest
steps:
- task: AdvancedSecurity-Codeql-Init@1
inputs:
languages: 'javascript,python'
enableAutomaticCodeQLInstall: true
# コンパイルや依存関係復元が必要な場合は、ここにビルド手順を追加する
- task: AdvancedSecurity-Codeql-Analyze@1対応する言語識別子は、csharp、cpp、go、java、javascript、python、ruby、swiftです。JavaとKotlinはjava、JavaScriptとTypeScriptはjavascript、CとC++はcppで扱います。(Microsoft Learn)
build modeの選択に注意する
code scanningでは、ビルドモードとしてnoneとmanualが説明されています。noneはコードベースをビルドせずにCodeQLデータベースを作る方式で、インタープリタ言語に加えて、C/C++、Java、C#でもサポートされます。一方、manualはビルド手順を明示する方式で、コンパイル言語の解析で重要になります。(Microsoft Learn)
注意点は、複数言語をまとめて指定する場合です。たとえばC#とJavaScriptをnoneで解析する構成は成立しやすい一方、noneをサポートしない言語を組み合わせるとパイプラインが失敗します。公式例では、C#とSwiftをnoneで組み合わせる構成は無効な例として示されています。(Microsoft Learn)
開発者は、次の観点で設定を確認してください。
- 対象言語が正しい識別子で指定されているか
- コンパイルが必要な言語で、InitとAnalyzeの間にビルド手順があるか
- キャッシュや増分ビルドによりCodeQLが必要な情報を取得できなくなっていないか
- self-hosted agentでCodeQL bundleが利用できるか
- 最初のスキャンを実行し、Advanced Securityタブに結果が出るか
pull request運用で確認すべきこと
code scanningを開発フローに組み込む場合、pull requestでの見え方を理解しておく必要があります。新しいコード変更でアラートが作成されると、pull requestのOverviewタブにannotationとして表示され、Advanced Security側でも確認できます。(Microsoft Learn)
ただし、annotationのコメント状態を解決しただけでは、根本のアラートを閉じたことにはなりません。pull requestのアラートを却下する場合は、アラート詳細画面からclose処理を行い、annotationとアラートの両方を適切に処理する必要があります。(Microsoft Learn)
運用ルールとしては、次のように決めておくと混乱を防げます。
| 判断項目 | 推奨ルール |
|---|---|
| 新規のHigh/Critical | 原則としてマージ前に修正 |
| False positive | 理由とコメントを残して却下 |
| Risk accepted | 期限、承認者、代替策を明記 |
| 既存脆弱性 | 新規混入とは別にバックログ化 |
| annotation解決 | コメント操作だけで終わらせず、アラート状態も確認 |
また、Advanced Securityのstatus checksをブランチポリシーに組み込むと、重大な脆弱性があるpull requestのマージを制御できます。公式情報では、すべてのCritical/Highをブロックするチェックと、新規のCritical/Highをブロックするチェックが説明されています。(Microsoft Learn)
展開・移行時に失敗しやすいポイント
code scanningの展開で失敗しやすいのは、機能そのものの有効化ではなく、周辺設定の見落としです。
| 失敗しやすいポイント | 起きる問題 | 対応策 |
|---|---|---|
| default setupだけで全ブランチを見ているつもりになる | リリースブランチや保守ブランチの問題を見落とす | 複数ブランチが必要なリポジトリはadvanced setupを検討 |
| コンパイル言語でビルド手順が不足する | CodeQLデータベース作成や解析が失敗する | InitとAnalyzeの間にクリーンなビルドを入れる |
| self-hosted agentにCodeQLがない | CodeQL関連ディレクトリが見つからず失敗する | 自動インストール設定または手動配置を行う |
| パイプライン定義リポジトリと解析対象リポジトリが異なる | 結果が意図しないリポジトリに紐づく | advancedsecurity.publish.repository.infer: trueを設定する |
| アラートを安易に却下する | 他ブランチの同一アラートも閉じられる | 却下理由、承認者、コメントを運用ルール化する |
| 無効化中も結果が残ると思い込む | 無効化中の実行結果を後から確認できない | 無効化期間を作らず、移行時は並行稼働で検証する |
特に、パイプライン定義を共通リポジトリに置き、実際のソースコードを別リポジトリからcheckoutする構成では注意が必要です。公式のトラブルシューティングでは、結果がパイプライン定義側のリポジトリに公開される可能性があるため、advancedsecurity.publish.repository.infer: trueで作業ディレクトリのリポジトリから公開先を推定させる方法が示されています。(Microsoft Learn)
self-hosted agentを使う場合も、CodeQL bundleの準備や必要な通信先の許可が必要です。公式情報では、CodeQL bundleをエージェントのtool cacheに置く方法や、enableAutomaticCodeQLInstall: trueを使う方法が説明されています。(Microsoft Learn)
管理者向けチェックリスト
展開前に、少なくとも次の項目を確認しておきましょう。
- 対象がAzure DevOps ServicesのAzure Repos Gitリポジトリである
- 対象リポジトリでCode SecurityまたはAdvanced Securityが有効になっている
- 新規リポジトリへの自動有効化を行うか決めている
- default setupとadvanced setupの使い分け基準がある
- default setupのエージェントプールとスキャン曜日を決めている
- パイプライン同時実行数への影響を確認している
- アラート閲覧、却下、設定変更の権限を分けている
- High/Criticalアラートの対応期限を決めている
- False positiveとRisk acceptedの承認ルールを決めている
- pull requestのstatus checksを使うか決めている
このチェックリストを満たさないまま全社展開すると、「スキャンは動いているが誰も直さない」「アラートが多すぎて見なくなる」「重要リポジトリだけ対象外だった」といった状態になりがちです。
開発者向けチェックリスト
開発者は、次の項目を確認するとトラブルを減らせます。
- 自分のリポジトリがdefault setupかadvanced setupか把握している
- 対象言語の指定が正しい
- コンパイル言語ではビルド手順がCodeQLのInit後、Analyze前にある
- pull requestのannotationだけでなくAdvanced Security側のアラート状態も確認している
- アラートの修正、却下、リスク受容の違いを理解している
- 既存脆弱性と新規脆弱性を分けて対応している
- スキャン失敗時にビルドログ、言語指定、エージェント設定を確認できる
開発者にとって重要なのは、code scanningを「レビューの邪魔」と捉えないことです。すべてのアラートを即日ゼロにするのではなく、新規の重大な問題を混入させないことから始めると、チームに定着しやすくなります。
まず取るべき対応
GitHub Advanced Security for Azure DevOpsのcode scanningは、default setupの整備により導入しやすくなっています。一方で、ブランチ戦略、ビルド方式、エージェント、権限、アラート運用まで決めないと、実効性のあるセキュリティ対策にはなりません。
まずは、重要度の高いAzure Repos Gitリポジトリを棚卸しし、default setupで始められるものとadvanced setupが必要なものに分けてください。次に、管理者は権限とエージェント設定を固め、開発者はCodeQLタスクの言語指定とビルド手順を確認します。最後に、High/Criticalの扱い、False positiveの承認、pull requestでのブロック条件をチームのルールに落とし込むことで、code scanningを継続的なセキュリティ改善につなげられます。
コメント