GitHub Advanced Security – Certificationsでまず押さえるべき結論は、「資格情報の更新」だけを見るのではなく、GitHub上のセキュリティ運用をどこまで実務で回せているかを確認する機会として捉えることです。対象は、GitHubとセキュリティ機能を深く理解し、ソフトウェア開発ワークフローを保護した経験を持つ人です。試験対策だけでなく、管理者・開発者・DevOps担当者が自社のSecret Protection、Supply Chain Security、Code Securityの設定を棚卸しするきっかけになります。(Microsoft Learn)
なお、Microsoft Learnの認定ページでは最終更新が「05/04/2026」、GH-500学習ガイドでは「Last updated on 2026-05-05」と表示されています。本記事では、2026年5月6日時点で公開されている公式情報をもとに、GitHub Advanced Security認定の変更点、影響範囲、管理者や開発者が確認すべき設定・展開上の注意点を整理します。(Microsoft Learn)
GitHub Advanced Security Certificationsとは
GitHub Advanced Security Certificationsは、GitHub Advanced Security、通称GHASを使って、コード、シークレット、依存関係をソフトウェア開発ライフサイクル全体で保護できるかを問う認定です。
公式ページでは、レベルは「中級」、対象ロールは管理者、開発者、DevOpsエンジニア、ソリューションアーキテクト、学生とされています。つまり、単にセキュリティ担当者だけの資格ではありません。リポジトリの管理、CI/CD、依存関係管理、アラート対応、開発チームへの展開まで関わる人が対象です。(Microsoft Learn)
特に重要なのは、試験が「機能名を暗記する人」ではなく、次のような実務経験を持つ人を想定している点です。
- GitHub Advanced Securityを使ってコード、シークレット、依存関係を保護した経験がある
- セキュリティ機能を構成できる
- アラートをトリアージし、修復まで進められる
- ポリシー、ワークフロー、自動化を使って予防優先の運用を設計できる
- GitHubの基礎、CI/CD、セキュア開発の考え方を理解している
受験を考えている人は、単なる試験対策ではなく「自分の組織でGHASをどう有効化し、誰がアラートを見て、どう修正するか」を説明できる状態を目指すべきです。
2026年5月時点の変更点は「大幅変更なし」だが、運用観点の整理が重要
GH-500学習ガイドの変更サマリーでは、FY26Q4の各スキル領域について「No change」と示されています。大枠の出題範囲が大きく変わったというより、GitHub Security Suites、Secret Protection、Supply Chain Security、Code Securityという整理に沿って、既存のGHAS運用を体系的に理解しているかが引き続き問われる内容です。(Microsoft Learn)
| 確認ポイント | 公式情報から読み取れること | 実務での対応 |
|---|---|---|
| 出題範囲 | FY26Q4では主要スキル領域に大きな変更なし | 既存の学習計画は継続しつつ、最新の用語に合わせて社内資料を更新する |
| 対象者 | GitHubとセキュリティ機能に深い理解がある経験者向け | 初心者向けGitHub基礎だけでは不足。GHASの設定・運用経験を積む |
| 重視領域 | Secret Protection、Supply Chain Security、Code Security、セキュリティ運用、管理 | 機能ごとの有効化だけでなく、アラート対応と権限設計まで確認する |
| 管理者への影響 | 組織・リポジトリ単位の設定、ポリシー、例外管理が重要 | 既存リポジトリ、新規リポジトリ、移管リポジトリの適用状況を棚卸しする |
ここで注意したいのは、「認定情報の更新＝GitHubの本番環境で自動的に設定が変わる」という意味ではないことです。今回確認すべきなのは、試験範囲が示す実務スキルと、自社のGitHub運用にズレがないかです。
試験で評価される6つの領域
公式ページでは、GH-500で評価される領域として次の6つが示されています。(Microsoft Learn)
| 領域 | 比率 | 管理者・開発者が実務で確認すべきこと |
|---|---|---|
| GitHub Security Suites、機能、エコシステムの説明 | 15〜20% | GHASの全体像、各セキュリティ機能の役割、Security Overviewの使い方 |
| Secret Protectionの構成と使用 | 15〜20% | secret scanning、push protection、カスタムパターン、バイパス権限 |
| Supply Chain Securityの構成と使用 | 15〜20% | Dependabot、Dependency Review、依存関係グラフ、SBOM、脆弱性対応 |
| Code Securityの構成と使用 | 10〜15% | CodeQL、code scanning、SARIF、既定セットアップと高度なセットアップ |
| セキュリティ運用、優先順位付け、修復 | 15〜20% | アラートのトリアージ、修復キャンペーン、誤検知対応、重大度判断 |
| GitHub Security Suites管理 | 10〜15% | Enterprise、Organization、Repository単位の設定、権限、ポリシー、展開 |
出題比率を見ると、特定機能だけを深掘りするより、GitHub上でセキュリティを継続運用する力が重視されていることが分かります。たとえばCodeQLだけを学んでも、Secret Protectionのバイパス運用やDependabotアラートの優先順位付けを説明できなければ、実務でも試験でも弱点になります。
管理者が確認すべき影響範囲
GitHub Advanced Security認定の更新情報を受けて、管理者が最初に確認すべき影響範囲は「誰が、どのリポジトリで、どのセキュリティ機能を、どの権限で運用しているか」です。
GitHub Docsでは、GitHubのセキュリティ機能には全プランで利用できるものと、GitHub Secret ProtectionやGitHub Code Securityなどの追加機能として利用するものがあると説明されています。Secret Protectionにはsecret scanningやpush protection、Code Securityにはcode scanning、premium Dependabot features、dependency reviewなどが含まれます。(GitHub Docs)
| 立場 | 影響を受けやすい領域 | 確認すべきこと |
|---|---|---|
| Enterprise管理者 | ライセンス、全体ポリシー、組織横断の展開 | GHAS関連機能の契約、利用範囲、Security Overviewの可視性 |
| Organization管理者 | security configurations、権限、既定設定 | 新規・既存・移管リポジトリに設定が適用されているか |
| リポジトリ管理者 | code scanning、secret scanning、Dependabot | ブランチ、ワークフロー、アラート通知、修復担当者 |
| 開発者 | push protection、dependency review、アラート修正 | PR前後で何がブロックされるか、どのアラートを優先するか |
| セキュリティ担当者 | トリアージ、例外承認、キャンペーン | 却下理由、期限、再発防止策、監査ログ |
影響範囲を見誤ると、GHASを有効化しても「アラートは出るが誰も直さない」「push protectionのバイパスが形骸化する」「DependabotのPRが大量に発生して開発現場が止まる」といった問題が起きます。認定範囲に含まれる機能は、試験用の知識ではなく、実運用の責任分界を整理するチェックリストとして使うのが現実的です。
GitHub管理者がまず確認すべき設定
Security configurationsとglobal settings
GitHubでは、組織全体のセキュリティ機能を管理するために、security configurationsとglobal settingsを使えます。security configurationsはリポジトリレベルの有効化設定をまとめて適用する仕組みで、global settingsは組織レベルの設定として各リポジトリに継承されます。(GitHub Docs)
管理者はまず、次の3点を確認してください。
| 確認項目 | 判断基準 | 注意点 |
|---|---|---|
| 既定のsecurity configuration | 新規リポジトリに必要な機能が自動適用されるか | 既定設定だけでは、移管されたリポジトリに自動適用されない場合がある |
| Enforce configuration | リポジトリ管理者による変更を許可するか | 強制しすぎると特殊なCI/CD構成のリポジトリで運用しづらくなる |
| 機能ごとの適用範囲 | Public、Private、Internalで必要な保護が違うか | Private/Internalでは利用コストやライセンス消費に注意する |
特に見落としやすいのが、移管されたリポジトリです。GitHub Docsでは、組織の既定security configurationは新規作成リポジトリに自動適用される一方、組織へ移管されたリポジトリには手動で適切なconfigurationを適用する必要があると説明されています。(GitHub Docs)
Secret Protectionの確認ポイント
Secret Protectionでは、シークレットの検出だけでなく、流出を未然に防ぐpush protectionや、組織独自のシークレットを検出するcustom patternsも重要です。
管理者は以下を確認しましょう。
| 項目 | 確認内容 |
|---|---|
| secret scanning alerts | アラートの通知先、対応者、期限が決まっているか |
| push protection | シークレットを含むpushをブロックできるか |
| delegated bypass | 誰がバイパスでき、誰が承認するか |
| custom patterns | 社内APIキー、独自トークン、環境固有の認証情報を検出できるか |
| dismissal policy | 却下理由、証跡、再確認のルールがあるか |
失敗しやすいのは、シークレットを削除しただけで対応完了にしてしまうことです。すでにコミット履歴やログに露出した可能性がある場合、削除だけでは不十分です。認証情報の無効化、再発行、影響範囲の確認まで対応フローに含める必要があります。
Supply Chain Securityの確認ポイント
Supply Chain Securityでは、Dependabot alerts、Dependabot security updates、dependency review、dependency graph、SBOMなどをまとめて考える必要があります。
開発現場で重要なのは、「脆弱性がある依存関係を検出する」だけでなく、「どのPRを先に処理するか」「自動更新をどこまで許可するか」「破壊的変更をどう検証するか」です。
| 項目 | 実務上の判断基準 |
|---|---|
| dependency graph | 利用している直接・推移的依存関係を可視化できているか |
| Dependabot alerts | 重大度、到達可能性、利用状況に応じて優先順位を付けているか |
| Dependabot security updates | 自動PRを許可する対象とタイミングが決まっているか |
| dependency review | PRマージ前に危険な依存関係の追加を検出できるか |
| private registry access | プライベートパッケージを使う場合、Dependabotやcode scanningが必要な情報へアクセスできるか |
GitHub Docsでは、組織がプライベートレジストリを使っている場合、code scanningやDependabotが安全にアクセスできるようにすることで、分析精度や更新対象の範囲を広げられると説明されています。(GitHub Docs)
Code Securityの確認ポイント
Code Securityでは、CodeQLによるcode scanning、SARIFの取り込み、外部CIとの連携、既定セットアップと高度なセットアップの使い分けが重要です。
特に管理者が注意すべきなのは、「全リポジトリに同じ設定を一括適用すればよい」と考えないことです。言語、ビルド方式、CI/CD、ランナー、モノレポ構成によって、適切なcode scanningの設定は変わります。
| 項目 | 確認内容 |
|---|---|
| default setup | 対象言語やリポジトリ構成で問題なく解析できるか |
| advanced setup | 独自ビルド、マトリクスビルド、外部CIが必要なリポジトリを識別しているか |
| runner | GitHub-hosted runnerで足りるか、self-hosted runnerが必要か |
| SARIF upload | 外部スキャンツールの結果をGitHubに統合するか |
| alert dismissal | 開発者が直接却下できる範囲と、承認が必要な範囲を決めているか |
GitHub Docsでは、custom security configurationでSecret ProtectionやCode Securityの有効化設定を作成でき、private/internal repositoriesに適用する場合は利用コストやGHASライセンスが必要になる可能性があると説明されています。(GitHub Docs)
移行・展開時に注意すべきポイント
今回の認定情報は、サービス停止や強制移行を知らせるものではありません。ただし、学習ガイドや公式ページの整理に合わせて、社内の運用資料や展開計画を見直す価値があります。
特に、旧称や従来の説明を使っている資料は、現在の出題・運用観点に合わせて更新しておくと混乱を防げます。
| 旧来の表現として残りやすいもの | 現在の整理で押さえたい表現 | 見直しポイント |
|---|---|---|
| secret scanning | Secret Protection | push protection、validity checks、custom patternsまで含めて説明する |
| Dependabot、Dependency Review | Supply Chain Security | 依存関係、SBOM、マージ前レビュー、アラート運用をまとめて扱う |
| Code scanning with CodeQL | Code Security | CodeQLだけでなく、SARIF、外部ツール、Copilot Autofixなどの周辺運用も確認する |
| GHASをリポジトリ単位で有効化 | Security configurationsで組織的に管理 | 新規・既存・移管・アーカイブ済みリポジトリの扱いを分ける |
展開時は、全リポジトリへ一斉適用するより、リスクと開発体制に応じて段階的に進める方が失敗しにくくなります。
推奨する展開手順
| 手順 | やること | 成功条件 |
|---|---|---|
| 現状把握 | リポジトリ、言語、CI/CD、依存関係、既存アラートを棚卸しする | どのリポジトリに何を適用するか分類できている |
| パイロット | 代表的な数リポジトリでSecret Protection、Code Security、Supply Chain Securityを有効化する | アラート量、誤検知、修復負荷を見積もれる |
| ルール化 | バイパス、却下、修復期限、通知先を決める | 開発者が「何をすればよいか」を迷わない |
| 段階展開 | 高リスク・高重要度のリポジトリから適用する | 開発速度を大きく落とさずに保護範囲を広げられる |
| 運用改善 | Security Overviewやキャンペーンで継続的に改善する | アラートが放置されず、修復状況を追跡できる |
展開の初期段階では、Enforce configurationをいきなり強くしすぎないことも重要です。既存の高度なCodeQL設定や独自CIを持つリポジトリでは、標準設定を上書きすると解析が失敗したり、期待したスキャンが動かなくなったりする可能性があります。まずは例外が必要なリポジトリを洗い出してから、強制適用の範囲を決めましょう。
開発者が確認すべき実務スキル
GitHub Advanced Security認定は管理者向けの要素が強い一方で、開発者の実務にも直結します。開発者が理解していないと、GHASを有効化しても修復が進みません。
開発者は次のスキルを確認してください。
| スキル | 実務での具体例 |
|---|---|
| push protectionへの対応 | シークレットを含むpushが拒否されたとき、原因を特定し安全に修正できる |
| Dependabot PRの判断 | 依存関係更新が破壊的変更を含むか、テストで確認できる |
| dependency reviewの読み取り | PRで追加されたパッケージの脆弱性やライセンスリスクを確認できる |
| code scanning alertの修正 | CodeQLの指摘内容を読み、該当コードを修正できる |
| alert dismissalの判断 | 誤検知、許容リスク、修正不要の理由を説明できる |
| セキュアなワークフロー設計 | CI/CD、Secrets、権限、ブランチ保護を組み合わせてリスクを下げられる |
ポイントは、アラートを「セキュリティチームからの指摘」として受け身で処理しないことです。依存関係を追加する、外部APIキーを扱う、Actions workflowを書く、PRをマージする。これらの日常作業の中で、セキュリティ判断を組み込むことが求められます。
受験・教育計画で確認しておきたいこと
公式ページでは、試験時間は100分、提供言語は英語、スペイン語、ポルトガル語、韓国語、日本語とされています。また、試験はMicrosoftによって提供されますが、試験と関連認定はGitHubによって維持されると説明されています。(Microsoft Learn)
社内で受験を推奨する場合は、次の点を事前に共有しておくと混乱を防げます。
| 項目 | 確認内容 |
|---|---|
| 受験対象者 | GitHub管理者、DevOps担当、セキュリティ担当、主要開発者 |
| 前提知識 | GitHub基礎、Actions、CI/CD、セキュア開発、依存関係管理 |
| 学習方法 | 公式学習ガイド、practice assessment、実リポジトリでの設定確認 |
| アカウント | 試験記録の管理を考え、登録に使うアカウントを慎重に選ぶ |
| 社内展開 | 合格者を増やすだけでなく、設定標準と運用ルールに反映する |
公式ページでは、試験登録には個人のMSAアカウントを使うことが強く推奨されています。組織の職場・学校アカウントで登録した場合、組織を離れた際に試験記録が失われ、復旧できない可能性があるためです。(Microsoft Learn)
よくある失敗と対策
アラートを出すだけで運用設計をしない
GHASを有効化すると、既存リポジトリの状態によっては多くのアラートが出ることがあります。担当者、優先順位、修復期限が決まっていないと、アラートが積み上がるだけです。
対策として、重大度だけでなく、公開範囲、悪用可能性、実行環境、依存関係の利用状況を含めて判断するルールを作りましょう。
開発者に説明せずpush protectionを有効化する
push protectionはシークレット流出を防ぐ有効な仕組みですが、開発者が理由を理解していないと「作業を邪魔する機能」と受け取られます。
有効化前に、ブロックされたときの対応手順、バイパス申請の条件、誤検知時の連絡先を共有しておくことが重要です。
private/internal repositoriesのコスト影響を見落とす
private/internal repositoriesにSecret ProtectionやCode Securityを適用する場合、契約やライセンス、利用状況の確認が必要です。設定変更の画面だけで判断せず、適用対象と費用影響を事前に確認しましょう。
既定設定だけで全リポジトリを保護できたと思い込む
新規作成リポジトリには既定設定が適用されても、移管されたリポジトリや特殊構成のリポジトリには追加対応が必要な場合があります。定期的にリポジトリ一覧を確認し、configurationの適用漏れをチェックしてください。
試験対策を暗記中心で進める
GH-500は、GitHubのセキュリティ機能を実務で使う前提の試験です。用語だけ覚えても、実際にアラートを見て修正した経験がないと理解が浅くなります。
学習時は、検証用リポジトリでsecret scanning、Dependabot、code scanningを有効化し、実際にアラート発生から修復まで試すのが効果的です。
まず取るべき次のアクション
GitHub Advanced Security Certificationsの公式情報を確認したら、次にやるべきことは受験申込だけではありません。自社のGitHub環境で、認定範囲に含まれる運用がどこまで実装されているかを確認しましょう。
最初の1週間で実施するなら、次の順番がおすすめです。
- GitHub組織内の重要リポジトリを一覧化する
- Secret Protection、Supply Chain Security、Code Securityの有効化状況を確認する
- security configurationsとglobal settingsの適用範囲を確認する
- アラートの担当者、通知先、修復期限、却下ルールを整理する
- 開発者向けにpush protectionやDependabot PRへの対応手順を共有する
- 受験予定者は公式学習ガイドとpractice assessmentで弱点領域を確認する
GitHub Advanced Security認定は、資格取得だけを目的にすると効果が限定的です。公式情報が示すスキル範囲を、自社のGitHubセキュリティ運用チェックリストとして使うことで、試験対策と実務改善を同時に進められます。
コメント