GitHub Advanced Securityに合格しました（受験レポとポイント解説）
GitHub Advanced Securityの試験を受けて合格することができました。
備忘がてらどういう風に勉強したかと出題される範囲の重要ポイントについて書いておきます。
GitHub Administrationの受験レポはこちらを！（試験の受験方法についても記載しています）
GitHubの資格試験のローカライズが開始された！とUniverse2024で聞いてワクワクしてたんですが、残念ながらGitHub Advanced Securityは2025年1月時点ではまだ英語でしか受験できませんでしたorz
GitHub Advanced Securityの試験範囲
その名の通りGitHub Advanced Security（以下GHAS）の機能に関する試験です。GHASの機能は主に以下3つで、これらの機能に関する知識が問われます。
- コードスキャン
- シークレットスキャン
- Dependabot
「この機能はどういうものですか？」という基本的な内容から、「コードスキャン/シークレットスキャン/Dependabotアラートの通知先」「CodeQLがソースコードを分析する仕組み」「Dependabotがアラートを生成する仕組み」などのデータフローや構造についての問題、「パブリックリポジトリでデフォルトで使用できる機能はどれか」「Organization/リポジトリでこれらのセキュリティの機能にアクセスできるのはどのアクセスレベルか、Enterpriseでorganization/リポジトリでGitHub Advanced Securityの○○の機能を利用させたい場合どのようにアクセスを構成するか」 のような管理者向けの知識も問われるので、GHASの機能に関連するアクセスレベル（構成できる人、アラートの通知が行く人、アラートの結果を受けて解決できる人）は暗記レベルで覚えた方がいいと思いました。
GHASの機能ってこういうのだよね！という知識だけで臨むともれなく爆死するので、学習ガイドをしっかり読んで各内容が理解できるレベルまで対策されることをおすすめします(;^_^A
学習ガイドはこちらです。
出題の内訳としてはこんな感じなので、
出題の割合が比較的高い以下を重点的に対策しました。
- Domain 3: Congure and use dependency management
- Domain4: Congure and use code scanning
- Domain5: Use code scanning with CodeQL
- Domain 6: Describe GitHub Advanced Security best practices
基本的にGHASの3つのセキュリティ機能とエンタープライズでのGHASの管理が問われる感じです。
学習リソース
Microsoftのラーニングパス
こちらにGitHub Advanced Securityのラーニングパスが公開されていますのでこれをまず1周、試験直後にもう1周しました。
割とすぐにできるボリューム感ですが、ふりかえってみるとほんとに試験で出題されるような内容が漏れなく、多すぎるということもなくちょうどいい感じにコンプリートされてました。
とはいえ、このラーニングパスの各モジュールの後の知識チェック全部OK！だけでは合格するのは難しいと思います。
github-certification-preparation-guideで各モジュールの内容を確認
GitHub Adminのときもお世話になったこちらのサイトで、各モジュールの理解度チェックができます。
Practice Testを解く
多くのGitHubの受験者の方がお世話になるであろうこちらのサイト。有志の方が模擬問題集を作ってくださっています。
単一選択、複数選択など実際に出題される問題の形式で、出題範囲のかなり広い範囲がカバーされています。絶対にここで練習したがいいです。
さらに各問題にはヒントになるGitHubの公式ドキュメントのリンクも記載されています。
ここの模擬問題で出てる内容を完璧に理解できるようにすればだいぶいい線いくと思います。
学習ガイドの全項目がわかるようにする
Practice Testをしっかりやり込むとだいぶ理解度は上がると思いますが、さらに合格の可能性を上げるためには学習ガイドで出されている各項目を全部回答できるようにするのが一番確実です。
（前回のGitHub AdminではPractice Testまでやりこんだものの、学習ガイドの内容全部理解するまでやる、というこのステップをおざなりにした結果超ギリでの合格だったのでその反省も込めて。。。）
学習ガイドでは、こんな感じにドメインごとに各質問？のようなものがかなり具体的に記載されています。
この内容に全部答えられるように準備しておくことでだいぶ仕上がります。
（私はGitHubのドキュメントを調べたり、ChatGPTに投げて公式ドキュメントのリンクを提示してもらったりして調べました）
今回の試験対策としては、こんな感じでやりました。
学習ガイドを眺めて出題内容を把握
↓
MS Learnのラーニングパスを1周して出題内容の全体像を把握
↓
github-certification-preparation-guideで知識チェック
↓
Practice Testをやりまくる
（間違えた問題や自信ない問題は全部ドキュメントを確認、CodeQLの仕組みとかDependabotアラートの生成の仕組みとかの若干複雑なやつは図を書く）
↓
学習ガイド全項目コンプリート
↓
学習ガイドの出題割合の高い順からMS Learnをもう1周
重要ポイントの解説
GHASの試験では、GHASの3つのセキュリティ機能の以下3つについての知識が多く問われます。各項目ごとに、「こういうのには引っかかるなよ！」というアドバイスも含めて学習ポイントを記載していきます。
- コードスキャン
- シークレットスキャン
- Dependabot
コードスキャン
コードベースに潜むセキュリティ的な脆弱性（XSSとかSQLインジェクションとか攻撃を受けやすいコード）を検知してくれる機能です。
Point1：コードスキャンとシークレットスキャンと混同しないように
コードスキャンはセキュリティ的な脆弱性やリスクの検知をしてくれますが、トークンや機密情報の有無のチェックはコードスキャンではできません。それをしてくれるのはシークレットスキャンです
シークレットスキャンと混同しないように気をつけてください。
Point2: CodeQLの基本用語の理解とコードスキャンの仕組みの理解
コードスキャンを理解するにあたって、以下のような用語の理解は必須です
- エクストラクタ
- CodeQL pack（Modelパック/Languageパック/Libraryパックなどパックの種類も把握しておく）
- quey suite
- Language Matrix
コードスキャンではCodeQLというGitHubが開発した静的解析のツールによってソースコードのスキャンを実施します（GitHub外からのCodeQLの利用も可。詳細は後述）。
CodeQLの分析の仕組みとしては以下のようになっています。
まず、エクストラクターによってコードベースのリレーションが解析され、CodeQLデータベースが作成されます。
※エクストラクターは言語ごとに動くため、解析対象のデータベースは対象の言語ごとに作成される
データベースに対してCodeQLクエリが実行され、セキュリティ的な脆弱性の有無がチェックされます。解析結果はSARIF(Analysis Results Interchange Format)ファイルで出力されます。
※CodeQLは解釈型（JavaScriptなどのコンパイル不要な言語）、コンパイル型（C#などコンパイルが必要な言語）のどちらの言語にも対応していますが、CodeQLの解析の仕方が違います。
解釈型の場合はソースファイルを直にウォッチし、コンパイル型の場合はビルドプロセスをウォッチします。
図のとおり、CodeQLの分析は実態としてはGitHub Actionsのワークフローとして実行されます。そのため、CodeQLの実行分はActionsの実行時間にカウントされます。
Point3: 外部からCodeQLを利用するパターンのプラクティスを押さえておく
外部からCodeQLを利用するシナリオとして、以下のようなパターンが考えられます。
- CI/CDサービスはGitHub Actions以外のものを使っていて、GitHub Actionsを使わずに自分のCI/CDサービスの中でCodeQLを使って分析したい
- ローカル環境でCodeQLを実行したい
このような場合は、CodeQL CLIを利用することで外部からCodeQLによる分析を実行することができます。
# codeqlのデータベースを作成
codeql database create ./db --language=python --source-root=./src
# codeqlで分析を実行
codeql database analyze ./db my-custom-query.ql --output=results.sarif
# codeqlの分析結果(SARIF)をGitHub CLIでGitHubリポジトリにアップロード
gh code-scanning upload --sarif=<SARIFファイルのパス> --repo=<リポジトリ名> --ref=<ブランチ名またはコミットSHA>
外部からGitHubにSARIFファイルをアップロードするためには、security-eventのwrite権限を持つPATもしくはGitHub Appが必要です。
これらのコマンドの実行順、分析でカスタムのクエリスイートを利用する方法、SARFI結果のアップロードに必要な権限については押さえておいてください。
シークレットスキャン
Point1: シークレットスキャンはデフォルトでは全パブリックリポジトリで有効になっていて、ユーザー側で無効にすることはできない
パブリック リポジトリでは、既定によりシークレット スキャンが有効になっており、構成したり無効にしたりすることはできません。 パブリック リポジトリでシークレット スキャンを構成または無効にする場合は、GitHub Advanced Security を使用してリポジトリをプライベート リポジトリに切り替える必要があります。
シークレットスキャンで意外とひっかけ？になりそうなのがこの仕様です。
シークレットスキャンを利用するにあたって、以下のパターンの前提条件を間違えないように気をつけてください。
| パターン | デフォルトで利用可能か | 必要な設定 |
|---|---|---|
| GHAS を有効にしていないパブリックリポジトリ | ✓ | デフォルトで有効。無効にもできない。 |
| GHAS を有効にしていないプライベートリポジトリ | × | GitHub Advanced Security (GHAS) を有効化する必要がある。 |
| GHAS を有効にしているパブリック/プライベートリポジトリ | ✓ | デフォルトで有効。プライベートリポジトリも利用可。 |
Point2: シークレットスキャンのスキャン対象
シークレットスキャンのスキャン対象はリポジトリのソースコードだけではありません
以下が対象となるので、こちらも間違えないように気をつけてください。
- リポジトリに存在する全ブランチのGit履歴全体
- issuesのタイトル、descriptionとコメント
- Discussionsのタイトル、コメント、description
- pull request のタイトル、説明とコメント
- Wiki
Point3: 新たにシークレットが検出された場合（増分スキャン）の通知先と履歴スキャンでシークレットが検出された場合の通知先の違い
シークレットスキャンでのシークレットの検出には、新たなコミットでシークレットがないかどうかを検出する増分スキャン(Incremental Scan)と、過去の履歴にシークレットのコミットがないかを検出する履歴スキャン(Historical scan)の2つがあります。この2つのスキャンでは、シークレットが見つかった場合のアラートの通知先が違うことに気をつけてください。
■増分スキャンの場合の通知先
- リポジトリのadmin
- セキュリティマネージャー
- read/writeのアクセス権を持つカスタムロールのユーザー
- （シークレットが検出されたリポジトリのadminである）Organization/EnterpriseのOwner
- commit author（権限に関わらず）
■履歴スキャン
- リポジトリのadmin
- セキュリティマネージャー
- read/writeのアクセス権を持つカスタムロールのユーザー
- （シークレットが検出されたリポジトリのadminである）Organization/EnterpriseのOwner
増分スキャンの場合は、権限に関わらずシークレットをコミットしてしまったcommit authorにも通知がいくことに注意してください。
Point4: シークレットスキャンのアラートの種類とアラートを解決できる権限
シークレットスキャンのアラートには以下の3種類があります。それぞれの種類の違いを抑えておいてください。
- ユーザー アラート
- プッシュ保護アラート
- パートナー アラート
また、アラートを確認したあと、アラートを「解決（アラート内容を確認し、クローズする）」することが必要になります。
この操作が可能なのは以下のアクセス権を持つユーザーです。上述の「アラートの通知先」と「解決できるユーザー」を混同しないように注意してください。
- リポジトリのOwner
- OrganizationのOwner
- セキュリティマネージャー
- admin権限をもつユーザー
Dependabotなどの依存関係管理関連のセキュリティ機能
コードベース使用している外部パッケージやライブラリに含まれる脆弱性（未修正のバグやセキュリティ的な脆弱性、アップストリームソース（本体）とのバージョン乖離によるリスク）に対応するための機能がDependabotです。Dependency graph（依存関係グラフ）、Dependency Review、Dependabotアラート、Dependabotセキュリティアップデート、Dependabotバージョンアップデートが依存関係の起因する脆弱性に対応するためのセキュリティ機能として提供されています。
依存関係管理関連の機能のそれぞれの違いや、アラートが生成される仕組みを理解するのがポイントになります。
Point1: Dependabot周りの機能とアラート生成の仕組みを理解する
依存関係に起因する脆弱性の検知からアラート生成、修正の提案までは以下のようになります。
GitHubにおける依存関係はDependency Graph（依存関係グラフ）で管理されています。この依存関係グラフに変更が発生した際には、GitHub Advisory DatabaseというGitHubが管理するオープンソースの脆弱性情報データベースで照合され、既知の脆弱性にマッチする場合はDependabotアラートが生成っされ、依存関係の脆弱性があることが通知されます。
※つまり、Dependabotアラートを使用するための前提条件として、「Dependency Graphを有効にしていること」が必要になります。（DependabotアラートはDependency Graphの情報をベースとするため）
検知された脆弱性がセキュリティ的な脆弱性に由来するものであれば、Dependabotセキュリティアップデートが発動して、Dependabotが脆弱性を解決するためのアップデートをプルリクエストとして作成してくれます。 セキュリティ的な脆弱性に関わらず、アップストリームソース（外部パッケージの本体）にアップデートがあり、リポジトリで使用中のパッケージバージョンと乖離がある場合には、Depndabotバージョンアップデートが発動し、バージョンアップのためのプルリクエストを自動で作成してくれます。
プルリクエストでは、Dependency Reviewという変更による依存関係の変更を表示してくれる機能があり、そこで依存関係がどのように変化するかを確認することができます。
Dependency Graph（依存関係グラフ）に変更が発生するトリガーは以下の2つです
- リポジトリ内の依存関係定義ファイル（package.jsonなど）に変更が発生する
- GitHub Advisory Databaseが更新される（GitHubが管理している既知の脆弱性リストが更新される）
https://docs.github.com/ja/code-security/supply-chain-security/understanding-your-software-supply-chain/about-the-dependency-graph
GitHub Advisory Databaseは、CVE(Common Vulnerabilities and Exposures)という脆弱性管理の基準で一意に管理されており、CWE(Common Weakness Enumeration)で脆弱性が分類されます。
Depnadbotアラートでは、これらの情報に加えて脆弱性の重要度が表示されますが、その重要度はCommon Vulnerability Scoring System)によってスコアリングされたものです。
これらの依存関係の脆弱性の検知、アラート生成、自動アップデートの生成までの仕組みやGitHub Advisoryの仕組み、Dependency Graphに変更が入るタイミングについてはしっかり押さえておいたほうがいいです。
Point2: Dependabotアラートは既定では有効になっていない
Practice Testで「あれ？GHASのセキュリティ系機能はパブリックリポジトリでは全部使えるよね？」とまんまと引っかかってしまいましたが、使用できはしますがデフォでは有効になっていません。
GitHub は、パブリック リポジトリ内の脆弱な依存関係を検出し、依存関係グラフを表示しますが、既定では Dependabot alertsは生成されません。 リポジトリのオーナーまたは管理者アクセス権を持つユーザーは、パブリック リポジトリに対して Dependabot alertsを有効にすることができます。
Point3: 依存関係に関連する機能の利用のための環境ごとの前提条件を理解
依存関係に関連するGitHubの機能で、以下のパターンでの利用できる前提条件を間違えないように気をつけてください。
- GHASなしのパブリックリポジトリ
- GHASなしのプライベートリポジトリ
- GHASありのパブリック/プライベートリポジトリ
| 機能 | GHASなしのパブリックリポジトリ | GHASなしのプライベートリポジトリ | GHASありのパブリック/プライベートリポジトリ |
|---|---|---|---|
| Dependency Graph | ✓ | ✓ | ✓ |
| Dependabotアラート | ✓ | × | ✓ |
| Dependabotセキュリティアップデート | ✓ | ✓ | ✓ |
| Dependabotバージョンアップデート | ✓ | ✓ | ✓ |
| GitHub Advisory Database | ✓ | ✓ | ✓ |
| Dependency Review | × | × | ✓ |
■利用のための前提条件
-
Dependabotアラート:
- 利用可能ではありますが、デフォでは有効化されていないので別途有効化する必要があります（Dependency Graphの有効化も必要）
-
Dependabotセキュリティアップデート:
- 手動での有効化が必要。Dependency Graphと Dependabot アラートが有効になっている必要があります
-
Dependabotバージョンアップデート:
- 手動での有効化が必要。Dependency Graphと Dependabot アラートが有効になっている必要があります
-
GitHub Advisory Database:
- デフォルトで利用可能です。
-
Dependency Review:
- GHASが有効化されている必要があります。
こちらで各機能のトップページに「利用できるユーザー」が記載されています。
その他のセキュリティ機能
コードスキャン、シークレットスキャン、Dependabotほどではありませんが、それ以外のセキュリティ機能についても出題範囲となっています。
以下についてはどんな機能であるか調べておくとよいでしょう。
- セキュリティポリシー
https://docs.github.com/ja/enterprise-cloud@latest/code-security/getting-started/adding-a-security-policy-to-your-repository#about-security-policies - セキュリティの概要
https://docs.github.com/ja/code-security/security-overview/about-security-overview - Security Advisory
https://docs.github.com/ja/enterprise-cloud@latest/code-security/security-advisories/working-with-repository-security-advisories/about-repository-security-advisories
Discussion