GitHub Secret Scanningアラートを受け取った時の初動対応を、secret種別、validity、公開範囲、失効、ログ確認、再発防止まで実務チェックリストで整理する。
何が起きたか
GitHub Secret Scanning のアラートは、リポジトリのGit履歴、issue、PR、Discussions、Wiki、secret gistなどに secretらしい値 が検出されたことを知らせる。ここでいうsecretには、Personal Access Token、APIキー、SSH秘密鍵、クラウド資格情報、SaaSトークン、Webhook署名鍵などが含まれる。
アラートが出た時点で「すでに侵害された」とは限らない。一方で、値が有効で、公開リポジトリやCIログに残っていた場合は、第三者に利用される前提で失効・ローテーションを進める必要がある。GitHub公式ドキュメントでも、検出後はsecretの種類、提供元、所有者、露出場所、validity、依存サービスを分けて確認する流れが示されている。
この記事は防御・確認・初動対応を目的にしています。検出されたsecretを使ってアクセスできるか試す方法、第三者環境への確認、攻撃再現、secret値の共有方法は扱いません。調査メモやチケットにもsecret値そのものは貼り付けず、識別子・時刻・対象・対応内容で記録します。
読者別の影響
Secret Scanningアラートは、開発者だけで処理してよい通知とは限らない。secretが参照する先は、クラウド、SaaS、CI/CD、顧客データ、管理画面、外部APIに広がるため、所有者と影響範囲を早く切り分ける必要がある。
| 読者・担当 | まず見るべきこと | 影響の考え方 |
|---|---|---|
| 開発者 | 検出場所、secret種別、該当コミット、ブランチ、PR | 自分の修正で混入したか、履歴やログにも残るかを確認する |
| SRE / DevOps | Actions Secrets、Deploy Key、クラウドキー、CI/CDログ | 本番デプロイやクラウド操作へ波及しないかを見る |
| 情シス・SaaS管理者 | PAT、SaaS APIキー、外部アプリ、管理者ロール | GitHub外のサービス側で失効・監査ログ確認が必要になる |
| SOC / CSIRT | validity、公開範囲、最終利用、不審操作、複数露出 | インシデントとして扱うべき優先度を判断する |
| 管理者 | Secret Scanning、Push Protection、例外承認、台帳 | 再発防止と例外運用が形骸化していないか確認する |
まず確認すること
初動の目的は、「本当に使えるsecretか」「どこへ露出したか」「何を止めるべきか」を短時間で判断することだ。GitHubの画面だけで完結させず、secretの提供元サービス側の管理画面や監査ログも確認する。
- アラートの対象リポジトリ、ブランチ、ファイル、行、PR、issue、Discussions、Wiki、secret gistを確認する。
- secretの種類と提供元を特定する。GitHub PAT、クラウドキー、SaaS APIキー、SSH秘密鍵などを混同しない。
- secretの所有者を確認する。個人、Bot、GitHub App、CI/CD、外部委託先のどれかを分ける。
- validityが分かる場合は、active、inactive、unknownを確認する。ただし最終判断は提供元サービス側で行う。
- 公開リポジトリ、fork、関連するCI/CDログ、release成果物、パッケージ成果物、複数箇所への露出を確認する。
- secretがアクセスできるリソース、権限、scope、最終利用、依存サービスを確認する。
- 失効、再発行、影響調査、履歴整理、関係者連絡の担当者を決める。
作業の詳細は GitHub secret leak対応チェックリスト に落とし込んでいる。報告文や初動メモが必要な場合は GitHubトークン漏えい対応テンプレート を併用する。
初動対応
すぐにやること
- active、公開リポジトリ、本番・管理者権限、複数箇所露出のsecretを優先して失効する。
- 失効前に、対象、検知時刻、露出場所、所有者、権限範囲を記録する。
- 必要なsecretは、最小権限、用途限定、期限付きで再発行する。
- GitHub側のアラートだけでなく、提供元サービス側の利用ログ、監査ログ、課金・操作履歴を見る。
- CI/CDやデプロイに影響する場合は、運用担当と調整し、停止時間や代替手段を記録する。
- Push Protection、validity checks、例外承認、secret台帳の運用状態を確認する。
やらないこと
- 最新コミットから値を削除しただけで対応完了にしない。
- secret値をチャット、チケット、報告書、スクリーンショットへそのまま貼らない。
- 第三者の環境や外部サービスに対して、secretが使えるか試さない。
- 履歴書き換えやforce pushを、証跡保全と関係者調整なしに急がない。
- 「privateリポジトリだから低リスク」と決めつけない。
- Push Protectionの例外を、理由・期限・承認者なしに許可しない。
記録すること
| 記録項目 | 残す内容 |
|---|---|
| 検知情報 | アラートID、リポジトリ、露出場所、検知時刻、検知者 |
| secret情報 | 種類、提供元、所有者、scope、validity、最終利用 |
| 対応 | 失効時刻、再発行時刻、実施者、影響サービス、復旧確認 |
| 影響確認 | 不審利用、clone、Actions実行、権限変更、外部サービス側ログ |
| 再発防止 | Push Protection、pre-commit、CI検知、secret台帳、教育、例外期限 |
判断基準
Secret Scanningアラートの優先度は、「値が見つかった場所」だけでなく、「まだ使えるか」「どの権限を持つか」「どれだけ外へ出た可能性があるか」で決める。
| 優先度 | 条件 | 推奨判断 |
|---|---|---|
| 高 | active、公開リポジトリ、production credential、管理者権限、クラウド・決済・顧客データに触れる | 直ちに失効し、ログ保全、CSIRT連携、影響調査を開始する |
| 中 | privateリポジトリ内だがactiveまたはunknown、CI/CDや社内SaaSへ接続する | 業務影響を確認しつつ、早期ローテーションとログ確認を行う |
| 低 | inactive、テスト専用、権限限定、外部露出なしが確認済み | 対象外根拠を残し、再発防止と台帳更新を行う |
判断に迷う場合は、公開範囲よりも「secretが持つ権限」を重く見る。テスト用に見えても、実際には本番APIや管理者権限に接続できることがあるからだ。
よくある誤解
「Secret Scanningが出たら侵害確定」
アラートは検出であり、侵害確定ではない。ただし、activeなsecretが公開範囲に出ている場合は、使われる前提で失効・ログ確認を進める。
「privateリポジトリなら急がなくてよい」
privateでも、外部委託先、退職者、漏えい済み端末、Actionsログ、fork、開発端末のローカルcloneへ広がる可能性がある。公開か非公開かだけで判断しない。
「履歴から消せば安全」
履歴整理は有効な場合があるが、失効の代わりにはならない。一度見えたsecretはコピーされている可能性があるため、まず使えない状態にする。
「Push Protectionの例外は開発速度のために自由に使ってよい」
例外は必要な場合があるが、理由、承認者、期限、対象リポジトリを残さないと、保護機能が形骸化する。GitHubのdelegated bypassのように、誰が例外を確認するかを決めておく。
関連用語・関連ページ
| 目的 | 内部リンク |
|---|---|
| 初動をチェックリスト化する | GitHub secret leak対応チェックリスト |
| 報告文と作業記録を作る | GitHubトークン漏えい対応テンプレート |
| 開発環境全体を見る | 開発ツール・OSSサプライチェーン確認チェックリスト |
| 初心者向けに練習する | GitHub secret leak 初動ミニCTF |
| 用語を確認する | Secret Scanning、Push Protection、Secrets Management、Access Token |
| 関連する事案を読む | マネーフォワードGitHub不正アクセス、開発ツール・OSSサプライチェーン確認 |
公式情報・参考情報
- GitHub Docs: Remediating a leaked secret in your repository
- GitHub Docs: Secret scanning
- GitHub Docs: Manage secret scanning alerts
- GitHub Docs: Enable validity checks
- GitHub Docs: Enable push protection
- GitHub Docs: Enable delegated bypass for push protection
- GitHub Docs: Secure use reference for GitHub Actions
まとめ
GitHub Secret Scanningアラートは、開発者個人のミス通知ではなく、認証情報の影響範囲を短時間で切り分けるためのインシデント初動の入口だ。重要なのは、secretの値を消すことではなく、使えなくすること、使われた可能性を確認すること、同じ混入を次回止めることだ。
まずは、secret種別、所有者、validity、公開範囲、権限、依存サービスを確認する。高リスクなら即時失効し、低リスクでも根拠を残す。次に、GitHub secret leak対応チェックリスト と GitHubトークン漏えい対応テンプレート へ進み、失効・ログ確認・再発防止まで作業化したい。
