Study guide for Exam GH-500: GitHub Advanced Security の更新で重要なのは、「試験範囲が変わった」だけではありません。GitHub Advanced Security（GHAS）の運用が、Secret Protection、Supply Chain Security、Code Security、Security Suites Administration という実務寄りの分類で整理され、管理者・開発者・セキュリティ担当者が確認すべき設定範囲も広がっています。
結論から言うと、GH-500を受験する人は古い学習メモをそのまま使わず、2026年7月時点の公式Study guideに合わせて学習範囲を組み直すべきです。企業でGitHubを管理している場合は、試験対策としてではなく、GHASの設定棚卸し資料として読み替えると実務に役立ちます。特に、シークレット漏えい防止、Dependabot関連の優先順位付け、CodeQLやSARIF連携、権限・例外・バイパスの管理は早めに確認しておきたいポイントです。Microsoft Learnの英語版では、GH-500のStudy guideが2026年7月時点の測定スキルとして掲載され、変更ログでも試験範囲が大きく変更されたことが示されています。 (Microsoft Learn)
GitHubのセキュリティ更新、管理者が確認すべき影響範囲と対応ポイント
GH-500の公式Study guideは、GitHub Advanced Securityの機能を単に覚えるための試験範囲表ではありません。現在のGitHubセキュリティ運用で重視される領域を、かなり実務に近い形で示しています。
今回のポイントは、従来の「secret scanning」「Dependabot」「CodeQLによるcode scanning」といった個別機能中心の見方から、次のようなセキュリティスイート単位の理解へ移っていることです。
| 領域 | 旧来の見方 | 2026年7月時点の整理 | 実務上の意味 |
|---|---|---|---|
| Secret Protection | secret scanning、push protection | シークレット漏えいの検出・防止・例外管理 | トークン流出を検出するだけでなく、push前に止める設計が必要 |
| Supply Chain Security | Dependabot、Dependency Review | 依存関係、SBOM、脆弱性アラート、優先順位付け | アラート件数ではなく、本番影響・EPSS・修正可能性で判断する |
| Code Security | CodeQL、code scanning | CodeQL、外部解析ツール、SARIF、Autofix、ワークフロー | CI/CDに組み込み、PR段階で脆弱性を減らす |
| Security Operations | アラート確認、修正 | キャンペーン、優先順位付け、所有者、ルールセット | 大量アラートをチーム横断で処理する運用が必要 |
| Security Suites Administration | 個別リポジトリ設定 | Enterprise、Organization、Repository単位の管理 | デフォルト設定、継承、権限、例外を標準化する |
GH-500の測定スキルは6領域に再構成され、Secret Protection、Supply Chain Security、Code Security、Security Operations、Security Suites Administrationが明確に分かれています。配点も各領域に分散しており、単一機能だけを深掘りするより、組織全体で安全に展開・運用できるかが問われる構成です。 (Microsoft Learn)
まず押さえるべき変更点
今回のStudy guide更新で最初に確認したいのは、機能名の変更ではなく「考え方の変更」です。GitHubのセキュリティ機能を、開発後にアラートを見る仕組みとしてではなく、SDLC全体でリスクを減らす仕組みとして扱う内容になっています。
「検出」より「予防」が重視されている
Study guideでは、push protection、dependency scanning、pre-merge analysisなど、開発の早い段階でリスクを止める内容が含まれています。これは、脆弱性やシークレット漏えいを後から検知して修正するだけではなく、PRやpushの時点で問題を減らす運用が求められているということです。 (Microsoft Learn)
たとえば、次のような運用が必要になります。
| 場面 | 従来ありがちな運用 | 見直すべき運用 |
|---|---|---|
| シークレット漏えい | アラートが出てから担当者が確認 | push protectionでpush時点にブロックし、例外は承認制にする |
| 依存関係の脆弱性 | Dependabotアラートを順番に処理 | EPSS、重大度、runtime依存、本番利用状況で優先順位を決める |
| コード脆弱性 | 定期的にスキャン結果を見る | PRチェック、CodeQL、外部CI、SARIF連携でマージ前に確認する |
| アラート管理 | 各リポジトリ管理者任せ | Security Overview、キャンペーン、所有者割り当てで組織的に処理する |
用語が新しい製品体系に寄っている
GitHub Docsでは、GitHub Code SecurityとGitHub Secret ProtectionがGitHub TeamおよびGitHub Enterprise Cloud上のアカウントで利用でき、一部の機能はGitHub.com上のパブリックリポジトリでも利用できると説明されています。また、GitHub Secret Protectionにはsecret scanningやpush protection、GitHub Code Securityにはcode scanning、プレミアムDependabot機能、Dependency Reviewなどが含まれます。 (GitHub Docs)
このため、社内資料では次のような表記の見直しが必要です。
| 古い表記の例 | 更新後に使いたい表記 | 補足 |
|---|---|---|
| secret scanning対策 | Secret Protection運用 | secret scanningだけでなくpush protection、custom patterns、bypassも含める |
| Dependabot対応 | Supply Chain Security対応 | Dependency Review、SBOM、EPSS、auto-triageも含める |
| CodeQL設定 | Code Security設定 | CodeQLだけでなく外部解析ツールやSARIF連携も含める |
| GHAS設定 | GitHub Security Suites管理 | Enterprise、Organization、Repository単位の有効化・継承を含める |
単なる表記ゆれに見えるかもしれませんが、運用範囲が変わるため注意が必要です。たとえば「Dependabotだけ確認している」状態では、Dependency ReviewやSBOM、優先順位付け、外部通知まで含めたSupply Chain Securityの観点では不足する可能性があります。
影響を受ける担当者
今回の更新は、GH-500受験者だけでなく、GitHub EnterpriseやOrganizationを管理するチームにも影響します。
| 担当者 | 影響範囲 | 確認すべきこと |
|---|---|---|
| GitHub管理者 | Enterprise、Organization、Repository単位のセキュリティ設定 | 既定値、継承、例外、ライセンス、GHESとの機能差 |
| セキュリティ担当者 | アラート運用、優先順位付け、キャンペーン | 重大度、EPSS、所有者、SLA、dismiss理由 |
| 開発者 | push protection、Dependency Review、CodeQLアラート | ブロック時の対応、PR修正、依存関係更新の判断 |
| DevOps担当者 | GitHub Actions、外部CI、SARIF、CodeQL workflow | スキャン頻度、matrix build、外部ツール連携、runner管理 |
| 教育・資格担当者 | GH-500学習資料、社内研修 | 旧ドメインや古い配点に基づく教材の更新 |
管理者が特に注意すべきなのは、機能を有効化しただけでは不十分という点です。Study guideでは、ポリシー、ワークフロー、自動化、delegated bypass、alert ownership、APIによる大規模設定まで含まれています。 (Microsoft Learn)
Secret Protectionで確認すべき設定
Secret Protectionは、シークレットの漏えいを検出し、push前に防ぐための領域です。Study guideでは、secret scanningの旧称に触れつつ、Secret Protectionとして設定・運用・例外管理まで扱っています。 (Microsoft Learn)
push protectionは「有効化したか」だけで判断しない
push protectionは、シークレットを含むコミットをブロックすることで漏えいを未然に防ぐ機能です。GitHub Docsでも、GitHub Secret Protectionの機能としてsecret scanning、push protection、custom patterns、delegated bypassなどが説明されています。 (GitHub Docs)
管理者は次の点を確認してください。
| 確認項目 | 実務での判断基準 |
|---|---|
| Organization全体で有効化しているか | 重要リポジトリだけでなく、新規作成リポジトリにも適用されるか確認する |
| public/private/internalで設定差がないか | リポジトリ種別やライセンス条件により利用可否が変わるため、棚卸しが必要 |
| bypass権限を誰に与えているか | 開発者全員ではなく、承認者・例外対応者を限定する |
| custom patternをdry runしたか | 誤検知が多いパターンをいきなりpush protectionに適用しない |
| アラート後の対応手順があるか | 「コードから削除」だけでなく、キーの無効化・再発行まで手順化する |
delegated bypassは例外管理の要
push protectionでシークレットが検出された場合、正当な理由があれば例外的にpushが必要になることがあります。GitHub Docsでは、delegated bypassにより特定のユーザー・ロール・チームへバイパス権限を付与でき、ほかのコントリビューターにはレビューサイクルを導入できると説明されています。バイパスリクエストは7日で期限切れになります。 (GitHub Docs)
実務では、次のようなルールを決めておくと混乱を防げます。
| ケース | 推奨対応 |
|---|---|
| 明らかな実シークレット | pushを止め、トークンを失効・再発行し、履歴から削除する |
| 誤検知の可能性がある文字列 | 開発者が理由を記載し、指定レビュー担当者が承認または却下する |
| 移行botや自動化アカウント | 信頼できるアカウントに限定して例外を設ける |
| よく使う社内トークン形式 | custom patternを作る前にdry runで誤検知率を確認する |
注意したいのは、例外を増やしすぎるとpush protectionの価値が下がることです。特に「開発速度を落としたくない」という理由で広範囲にバイパス権限を与えると、実際の漏えいも見逃しやすくなります。
custom patternは段階的に展開する
社内独自のAPIキーやアクセストークン形式を検出するには、custom patternが有効です。ただし、GitHub Docsでは、custom patternのpush protectionを有効化する前にdry runで結果を確認する流れが示されており、一般的に出現しやすいパターンを有効化すると開発者の作業を妨げる可能性があるとも説明されています。 (GitHub Docs)
おすすめの展開順は次の通りです。
| ステップ | 作業 |
|---|---|
| 1 | 既存の社内トークン形式を洗い出す |
| 2 | custom patternを作成する |
| 3 | dry runで誤検知を確認する |
| 4 | 検出結果をセキュリティ担当と開発チームでレビューする |
| 5 | 重要リポジトリから段階的にpush protectionへ適用する |
| 6 | bypass理由と誤検知パターンを定期的に見直す |
Supply Chain Securityで確認すべき設定
Supply Chain Securityは、依存関係の脆弱性、Dependency Review、SBOM、Dependabotアラート、セキュリティ更新をまとめて扱う領域です。Study guideでは、旧Dependabot/Dependency Reviewという表現から、サプライチェーン全体のリスク管理へ広がっています。 (Microsoft Learn)
Dependabotアラートは件数ではなく優先順位で見る
依存関係の脆弱性は、すべてを同じ優先度で処理するとすぐに運用が破綻します。Study guideでは、EPSS scoring、security campaigns、pull requests、auto-dismiss behaviorなどが含まれています。EPSSは脆弱性が今後30日以内に悪用される確率を示すスコアとしてGitHub Docsでも説明されています。 (Microsoft Learn)
実務では、次の順に優先順位を決めると判断しやすくなります。
| 優先度 | 判断基準 | 対応例 |
|---|---|---|
| 最優先 | critical/high、runtime依存、本番利用、EPSSが高い、修正バージョンあり | 即時アップデート、緊急PR、リリース調整 |
| 高 | highまたはmedium、本番影響あり、修正可能 | スプリント内で修正 |
| 中 | devDependency、検証環境のみ、影響限定的 | 定期メンテナンスで更新 |
| 低 | パッチ未提供、影響なし、誤検知に近い | snooze、dismiss、理由を記録 |
ここで重要なのは、dismissを「無視」として使わないことです。dismissする場合は、なぜリスクが低いと判断したのか、再確認する条件は何かを記録する必要があります。
auto-triage rulesは通知ノイズを減らすが、乱用しない
GitHub Docsでは、Dependabotのcustom auto-triage rulesを使うことで、アラートのdismiss、snooze、Dependabotにpull requestを開かせる条件を制御できると説明されています。ルールは通知前に適用されるため、低リスクアラートの通知ノイズを減らす用途に向いています。 (GitHub Docs)
ただし、次のような設定は避けるべきです。
| 避けたい設定 | 問題点 |
|---|---|
| medium以下をすべて自動dismiss | runtime依存や悪用可能性の高い脆弱性を見逃す可能性がある |
| patch unavailableを永続dismiss | 後日パッチが公開されても再確認されにくい |
| 特定エコシステムを一律除外 | npm、Maven、PyPIなどの実際の利用状況を無視してしまう |
| Dependabot PRを無制限に作成 | PRが大量発生し、開発者が処理しきれない |
おすすめは、まず「devDependencyかつ低重大度」「パッチ未提供で一時snooze」など、影響が限定的な条件から始めることです。運用が安定してから、組織レベルでenforcedにするかどうかを判断します。
Dependency ReviewはPR運用とセットで考える
Dependency Reviewは、依存関係の変更をマージ前に確認するための機能です。GitHub Docsでは、GitHub Code Securityの機能として、PRをマージする前に依存関係変更の影響や脆弱なバージョンの詳細を表示すると説明されています。 (GitHub Docs)
開発チームには、次のようなルールを共有しておくと実務で使いやすくなります。
| PRで発生した状況 | 開発者の対応 |
|---|---|
| 新しい脆弱な依存関係が追加された | 代替バージョン、別ライブラリ、修正済みバージョンを検討する |
| licenseやcomplianceの問題がある | 法務・セキュリティ担当に確認してからマージする |
| Dependabot PRでテストが失敗した | 依存関係の破壊的変更を確認し、必要に応じて段階的に更新する |
| 複数の依存関係が同時更新された | 重要パッケージを分けて更新し、障害時の切り戻しをしやすくする |
Code Securityで確認すべき設定
Code Securityは、CodeQLによるcode scanningだけではありません。Study guideでは、CodeQL、サードパーティ解析ツール、SARIF、workflow templates、matrix builds、scan frequency、Autofix、スキャン失敗時のトラブルシューティングまで含まれています。 (Microsoft Learn)
CodeQL workflowは「動いている」だけでは不十分
CodeQLのworkflowは、push、pull request、スケジュール実行など、いつスキャンするかが重要です。GitHub Docsでは、CodeQL analysis workflowをスケジュールや特定イベントで実行でき、pushやpull requestでのスキャンは新しい脆弱性やエラーの導入防止に役立つと説明されています。 (GitHub Docs)
管理者・DevOps担当者は、次の項目を確認してください。
| 確認項目 | 見落としやすいポイント |
|---|---|
| pull_requestでスキャンしているか | default branchだけのスキャンでは、PR段階で止められない |
| protected branchを対象にしているか | 重要ブランチにworkflowが存在しないと想定通り動かない場合がある |
| schedule実行があるか | 開発が止まっているリポジトリでも新たに判明した脆弱性を検出できる |
| matrix buildが必要か | 言語、OS、ビルド条件が複数ある場合にスキャン漏れが起きやすい |
| self-hosted runnerを使っているか | CodeQL databaseや一時ファイルの扱いを確認する |
| 外部CIと併用しているか | 結果をSARIFでGitHubへ取り込めるか確認する |
SARIF連携は外部ツール利用時の重要ポイント
サードパーティの静的解析ツールや外部CIを使う場合、SARIFファイルをGitHubへアップロードすることで、code scanningの体験内でアラートを確認できます。GitHub Docsでは、code scanningがSARIF 2.1.0 JSON schemaの一部をサポートし、GitHub Actions、code scanning API、CodeQL CLIでアップロードできると説明されています。 (GitHub Docs)
外部ツールを使う場合の確認ポイントは次の通りです。
| 項目 | 確認内容 |
|---|---|
| SARIFバージョン | GitHubがサポートするSARIF 2.1.0形式か |
| location情報 | GitHub上でコード行に正しく紐づくか |
| severityの扱い | 自社の重大度基準とGitHub上の表示が合うか |
| 重複アラート | CodeQLと外部ツールで同じ問題が二重に出ていないか |
| アップロード方法 | GitHub Actions、API、CodeQL CLIのどれを使うか |
Copilot Autofixは便利だが、レビュー前提で使う
GitHub Docsでは、Copilot Autofixがcode scanningアラートの修正に役立つ提案を提供し、新しい脆弱性の導入を避ける支援をすると説明されています。また、public repositoriesやGitHub Code Securityが有効なGitHub Teamの組織所有リポジトリで利用できるとされています。 (GitHub Docs)
ただし、Autofixの提案はそのまま採用するのではなく、次の観点でレビューするべきです。
| レビュー観点 | 確認内容 |
|---|---|
| セキュリティ | 元のアラートを本当に解消しているか |
| 仕様 | 業務ロジックや入力条件を壊していないか |
| テスト | 既存テスト・追加テストで確認できるか |
| 保守性 | 一時的な回避ではなく、読みやすい修正になっているか |
| 影響範囲 | 同じパターンの脆弱性が別ファイルにもないか |
Autofixは開発者の修正速度を上げる道具ですが、最終判断は人間のレビューとテストに残すのが安全です。
Security Operationsで確認すべき設定
Security Operationsの領域では、アラートをどう処理するか、どの順番で直すか、誰が責任を持つかが問われます。Study guideには、CVE、CWE、GitHub Security Advisory、severity、remediation rulesets、security campaigns、bulk alert management、alert dismissal documentationなどが含まれています。 (Microsoft Learn)
Security Overviewをアラート一覧ではなく管理画面として使う
Security Overviewは、組織やEnterprise全体のセキュリティ状態を把握するための重要な入口です。GitHub Docsでは、Security Overviewのフィルターは表示ビューやOrganization/Enterpriseレベルによって異なり、複数フィルターは基本的にAND条件で適用されると説明されています。 (GitHub Docs)
実務で使う場合は、次のようなフィルター観点を用意しておくと便利です。
| 見たい状態 | フィルター例の考え方 |
|---|---|
| 重要リポジトリの未対応アラート | production、topic、team、repository propertyなどで絞る |
| 放置されている脆弱性 | open期間、severity、alert typeで確認する |
| push protection未適用リポジトリ | security feature enablement系の条件で確認する |
| Dependabotが有効でないリポジトリ | dependency graphやDependabot設定の有無を確認する |
| dismissが多いチーム | dismiss理由、担当チーム、リポジトリ単位で確認する |
dismissalは「閉じる」ではなく「説明責任を残す」
大量のアラートがある環境では、すべてを即修正できないことがあります。そのためdismissやsnoozeは必要です。ただし、理由のないdismissは危険です。
実務では、dismiss理由を次のように分類しておくと監査や引き継ぎで困りにくくなります。
| 理由 | 記録すべき内容 |
|---|---|
| false positive | なぜ誤検知と判断したか |
| not used in production | 本番に到達しない根拠 |
| vulnerable code not reachable | 到達不能と判断した根拠 |
| patch unavailable | 次回確認日、代替策 |
| risk accepted | 承認者、期限、補償策 |
「あとで見る」は理由になりません。期限や再確認条件がない保留は、実質的に放置と同じです。
GitHub Security Suites Administrationで確認すべき設定
Administration領域では、個別リポジトリではなく、Enterprise、Organization、Repositoryの階層でセキュリティ機能をどう展開するかが重要です。Study guideでは、security suitesの有効化、GitHub Enterprise CloudとGitHub Enterprise Serverの機能差、default configurations、inheritance behavior、rulesets、bypass permissions、APIsによる自動化が含まれています。 (Microsoft Learn)
大規模展開では「例外ルール」を先に決める
GHASを大規模に展開すると、必ず例外が発生します。たとえば、古いリポジトリでCodeQLがビルドに失敗する、依存関係更新で互換性問題が出る、移行botがpush protectionに止められる、といったケースです。
展開前に決めておくべきルールは次の通りです。
| ルール | 決める内容 |
|---|---|
| 適用対象 | すべてのリポジトリか、重要リポジトリから段階適用か |
| 除外条件 | archived、検証用、PoC、非本番などをどう扱うか |
| 例外承認 | 誰が、どの期限で、どの証跡を残して承認するか |
| dismiss権限 | 開発者、管理者、security managerのどこまで許可するか |
| bypass権限 | push protectionの例外を誰が承認するか |
| 自動化 | API、GitHub Actions、外部チケットシステムとどう連携するか |
GitHub Enterprise Serverでは機能差を確認する
Study guideでは、GitHub Enterprise CloudとGitHub Enterprise Serverの機能可用性の違いを理解することも対象になっています。GHESを利用している場合、GitHub.comのドキュメントだけを見て判断すると、利用中のバージョンで機能が未対応、または設定画面が異なる可能性があります。 (Microsoft Learn)
GHES環境では、次の順で確認すると安全です。
| 確認順 | 内容 |
|---|---|
| 1 | 利用中のGHESバージョンで対象機能が使えるか |
| 2 | GitHub.com向けドキュメントとGHES向けドキュメントの差分 |
| 3 | GitHub Actions、CodeQL、Dependabot、secret scanningの前提条件 |
| 4 | ネットワーク制約や外部通信の可否 |
| 5 | アップグレード計画と機能展開時期 |
管理者向けチェックリスト
GH-500のStudy guide更新を、社内のGitHubセキュリティ点検に使うなら、次の順で確認すると効率的です。
| 優先度 | チェック項目 | 確認内容 |
|---|---|---|
| 高 | 用語・社内資料の更新 | Secret Protection、Supply Chain Security、Code Securityの新しい分類に合わせる |
| 高 | Security Overview | Organization/Enterprise単位でアラートを確認できる担当者を決める |
| 高 | Secret Protection | push protection、custom patterns、delegated bypass、alert recipientsを確認する |
| 高 | Supply Chain Security | dependency graph、Dependabot alerts、security updates、Dependency Reviewを確認する |
| 高 | Code Security | CodeQL workflow、scan frequency、PRチェック、SARIF連携を確認する |
| 中 | アラート運用 | severity、EPSS、patch availability、runtime影響で優先順位を定義する |
| 中 | 権限管理 | dismiss、bypass、security manager、repository adminの権限を整理する |
| 中 | 例外管理 | 例外の承認者、期限、証跡、再確認条件を決める |
| 中 | GHES確認 | 利用バージョンで対象機能が使えるか確認する |
| 低 | 資格対策資料 | 古いGH-500対策資料の配点・用語・出題範囲を見直す |
開発者へ展開するときの伝え方
セキュリティ機能を有効化するだけでは、現場に負担がかかることがあります。特にpush protectionやDependency Reviewは、開発者の作業を直接止める可能性があります。
展開時は、「止めるための仕組み」ではなく「事故を早く見つけて、手戻りを減らす仕組み」として説明するのが効果的です。
push protectionで止まった場合の対応例
開発者向けには、次のような短い手順を用意しておくと混乱を防げます。
| 状況 | 対応 |
|---|---|
| 本物のAPIキーをcommitした | pushせず、キーを失効・再発行し、commitから削除する |
| テスト用のダミー値だった | 誤検知か確認し、必要なら命名や値を変更する |
| 業務上どうしてもpushが必要 | bypass requestを出し、理由を明記する |
| 何をすべきか分からない | セキュリティ担当またはリポジトリ管理者に相談する |
開発者にとって一番困るのは、ブロックされた後に誰へ相談すればよいか分からないことです。機能を有効化する前に、問い合わせ先と対応時間を決めておきましょう。
PRテンプレートに入れるとよい確認項目
PR運用に組み込むなら、次のような確認項目が実用的です。
## セキュリティ確認
- 新規または更新した依存関係に未対応の重大な脆弱性がない
- secret scanningまたはpush protectionの警告を意図的に回避していない
- CodeQLまたはcode scanningの新規アラートを確認した
- セキュリティ例外が必要な場合は理由と期限を記載したこの程度であれば、開発者の負担を増やしすぎず、レビュー時の会話を始めやすくなります。
GH-500対策としての学習順
GH-500を受験する場合は、個別機能をばらばらに覚えるより、実務の流れに沿って学習した方が定着しやすくなります。
| 学習順 | 学ぶ内容 | ハンズオン例 |
|---|---|---|
| 1 | GitHub Security suites全体像 | Secret Protection、Code Security、Supply Chain Securityの違いを整理する |
| 2 | Secret Protection | secret scanning、push protection、custom patterns、bypassを試す |
| 3 | Supply Chain Security | Dependency Review、Dependabot alerts、EPSS、auto-triageを確認する |
| 4 | Code Security | CodeQL workflow、PRスキャン、SARIFアップロードを試す |
| 5 | Security Operations | Security Overview、dismiss理由、campaign、優先順位付けを整理する |
| 6 | Administration | Enterprise/Organization/Repository単位の設定、権限、例外を確認する |
Microsoft LearnのGH-500ページでは、受験者にはGHASを使ってコード、シークレット、依存関係をSDLC全体で保護する経験が求められると説明されています。つまり、画面名を暗記するだけでなく、どの設定をどの階層で有効化し、アラートをどう運用するかまで理解しておく必要があります。 (Microsoft Learn)
古い学習資料・社内手順を使うときの注意点
GH-500の学習記事や社内手順には、旧名称や旧分類で書かれたものが残っている可能性があります。特に、次のような資料は見直しが必要です。
| 古い資料の特徴 | リスク |
|---|---|
| secret scanningだけをシークレット対策として説明している | push protection、delegated bypass、custom patternsを見落とす |
| Dependabotだけを依存関係対策として説明している | Dependency Review、SBOM、EPSS、auto-triageを見落とす |
| CodeQLだけをコードスキャンとして説明している | 外部解析ツールやSARIF連携を見落とす |
| リポジトリ単位の設定だけを説明している | Organization/Enterpriseの既定値や継承を見落とす |
| アラート対応を開発者任せにしている | 所有者不明、dismiss乱用、SLA未定義になりやすい |
日本語版のMicrosoft Learnページは、英語版と更新日や表現が異なる場合があります。Microsoft LearnのStudy guideでは、ローカライズ版の試験は英語版更新からおおむね約8週間後に更新されることがあると説明されています。試験対策や社内展開では、最新の英語版Study guideを基準に確認し、日本語版は補助資料として扱うのが安全です。 (Microsoft Learn)
まとめ：GH-500更新はGHAS運用を見直すよい機会
Study guide for Exam GH-500: GitHub Advanced Security の更新は、資格試験の出題範囲変更にとどまりません。GitHub Advanced Securityを、個別機能の寄せ集めではなく、シークレット、依存関係、コード、運用、管理を横断するセキュリティスイートとして扱う流れが明確になっています。
管理者が最初に行うべきことは、すべての機能を一気に有効化することではありません。まず、現在のOrganizationやRepositoryで、Secret Protection、Supply Chain Security、Code Securityがどこまで有効になっているかを棚卸しします。そのうえで、push protectionの例外管理、Dependabotアラートの優先順位付け、CodeQL workflowとSARIF連携、Security Overviewによる可視化、dismissやbypassの権限設計を順番に整備してください。
GH-500を受験する人は、公式Study guideの6領域に合わせて学習計画を作り直しましょう。企業でGitHubを運用している人は、同じ内容をセキュリティ設定のチェックリストとして使うと、試験対策と実務改善を同時に進められます。
コメント