GitHubの非公開リポジトリを誤ってPublicにした、または公開範囲の設定ミスに気づいた時の初動対応を解説。非公開化、シークレット失効、履歴・フォーク・Actions・監査ログの確認、影響評価、社内報告、再発防止を、開発者・情シス・SaaS管理者向けチェックリストで整理します。
この記事の目次 13項目から選ぶ
冒頭要約
GitHubの非公開リポジトリを誤ってPublicにした場合、Privateへ戻すだけでは対応完了ではありません。公開中にコードが閲覧・複製された可能性に加え、過去のコミット、別ブランチ、Pull Request、Issue、Wiki、Release、GitHub Actionsのログや成果物に、シークレットや社内情報が残っている場合があります。
最初に行うのは、検知時刻と対象リポジトリを記録し、権限があれば速やかに非公開へ戻すことです。続いて、APIキー、トークン、パスワード、秘密鍵などを発行元で失効し、GitHubの履歴・フォーク・監査ログと、認証情報が使える外部サービスのログを確認します。
この記事では、開発者、情シス、SaaS管理者、CSIRTが、誤公開を発見してから影響評価、報告、復旧、再発防止へ進む順番を整理します。履歴改変の具体的なコマンドや第三者データへのアクセス方法は扱わず、防御と初動判断に必要な情報だけを解説します。
認証情報が含まれていた場合は、ファイル削除やGit履歴の書き換えより先に、発行元で失効・ローテーションしてください。履歴から見えなくしても、すでに複製された認証情報は無効になりません。
GitHubリポジトリの誤公開とは
リポジトリの誤公開とは、本来は限定されたメンバーだけが参照すべきコードや文書を、設定ミスや運用ミスによって広い範囲から閲覧できる状態にすることです。代表例は、PrivateリポジトリをPublicへ変更した、InternalとPrivateを取り違えた、公開用リポジトリへ社内ファイルを移した、といったケースです。
GitHubの可視性は主に次のように整理できます。
| 可視性 | 主な閲覧範囲 | 誤解しやすい点 |
|---|---|---|
| Public | インターネット上の誰でも閲覧可能 | URLを知らせていなくても公開状態であり、フォークや複製が可能 |
| Private | 明示的にアクセスを付与された利用者 | 外部連携、Actions、Deploy keyなど別のアクセス経路も確認が必要 |
| Internal | 同じEnterpriseのメンバー | 特定チームだけのPrivateと同じではなく、組織設計によって閲覧範囲が広い |
GitHub公式ドキュメントでは、PublicからPrivateへ戻しても、公開中に作成されたPublic forkは自動でPrivateにならず、元リポジトリから切り離される場合があると説明されています。また、PrivateからPublicへ変更するとActionsの履歴やログも公開対象になります。コード本体だけでなく、周辺機能を含めて確認する必要があります。
読者別の影響：誰が何を確認するか
| 読者 | 最初に確認すること | 主な責任範囲 |
|---|---|---|
| 開発者・リポジトリ管理者 | 可視性、公開期間、ブランチ、タグ、PR、シークレット、Actions | 非公開化、技術的な影響範囲の特定、認証情報のローテーション |
| 情シス・SaaS管理者 | GitHub Organizationの監査ログ、管理者権限、外部連携、SSO | 操作主体の確認、アカウント・権限の封じ込め、組織内調整 |
| CSIRT・セキュリティ担当 | 情報分類、外部コピーの可能性、関連システムのログ | 優先度判断、証跡保全、調査範囲、経営・法務へのエスカレーション |
| 個人開発者 | 公開したファイル、環境変数、個人情報、利用中のAPIキー | 非公開化、認証情報の失効、関係者への連絡 |
顧客情報、従業員情報、契約情報、未公開機能、インフラ構成が含まれる場合は、コードの問題だけではありません。社内の情報セキュリティ、プライバシー、法務、顧客対応の手順に従い、必要な担当者へ早めに共有します。
まず確認すること：最初の15分チェックリスト
1. 検知時点を記録する
- リポジトリの所有者、名称、URL、発見日時、発見者を記録する。
- 現在の可視性と、本来あるべき可視性を記録する。
- いつPublicまたはInternalへ変わったか、分かる範囲で時刻を記録する。
- 発見経路と、すでに実施した操作を時系列で残す。
スクリーンショットを残す場合は、シークレットや個人情報が写った画像を通常のチャットへ貼らず、組織の証跡保全ルールに従います。
2. リポジトリを非公開へ戻す
- 自分に変更権限があり、誤公開であることが明らかなら、Privateへ戻す。
- 権限がない場合は、Organization ownerやリポジトリ管理者へ緊急連絡する。
- GitHub Pages、Packages、Release、Actions artifactなど、別に公開される成果物がないか確認する。
- 公開URLを社内外へ再共有せず、対応用チケットや限定された連絡経路で共有する。
可視性変更は影響拡大を止めるための封じ込めです。一方で、Privateへ戻したことは「誰も見ていない」ことの証明にはなりません。公開期間と情報の内容をもとに、その後の調査を続けます。
3. 公開されていた範囲を洗い出す
現在のデフォルトブランチだけでなく、次を対象にします。
- コミット履歴、全ブランチ、タグ。
- Pull Requestの差分、レビューコメント、添付ファイル。
- Issue、Discussion、Wiki、Gistへの転記。
- Release assets、Packages、GitHub Pages。
- GitHub Actionsの実行ログ、artifact、キャッシュ、環境名。
- README、設定ファイル、サンプルデータ、テストデータ、設計資料。
- 公開中に作られたforkや、把握しているclone・ミラー。
「ファイル一覧には見当たらない」だけでは、過去のコミットや別サーフェスに残っていないとは判断できません。
4. 情報を分類する
| 情報 | 例 | 最初の対応 |
|---|---|---|
| 認証情報 | APIキー、アクセストークン、パスワード、秘密鍵、Webhook secret | 発行元で失効し、新しい値へ切り替える |
| 個人・顧客情報 | 氏名、連絡先、識別子、取引・サポート情報 | 取り扱い責任者、セキュリティ、法務へ報告する |
| 機密コード・設計 | 未公開コード、構成図、内部URL、運用手順 | 悪用可能性と事業影響を評価し、必要な防御変更を行う |
| テストデータ | 架空データ、匿名化データ、ダミーのsecret | 本当に無効・架空かを所有者が確認し、判断根拠を記録する |
| 公開前提の情報 | OSSコード、公開済み文書 | 誤公開経路と設定ミスは記録し、他の機密情報が混在していないか確認する |
データ分類が未整備な場合は、「外部公開可能」「社内限定」「機密」「認証情報」のように暫定分類し、情報の所有者を決めて確認します。
5. シークレットを失効・ローテーションする
認証情報が見つかったら、次の順で進めます。
- どのサービスが発行した認証情報かを特定する。
- そのサービスの正規管理画面で失効またはローテーションする。
- CI/CD、ホスティング、SaaS、アプリ設定を新しい値へ切り替える。
- 発行元の利用ログ、課金、設定変更を確認する。
- 旧認証情報が利用不能になったことを、安全な管理画面で確認する。
漏えいした可能性がある認証情報を「使えるか試す」ために実行しないでください。発行元で状態を確認し、失効を優先します。実作業はGitHub secret leak対応チェックリストとGitHubトークン漏えい対応テンプレートに記録できます。
6. 可視性変更と周辺操作を監査する
Organization管理者は監査ログで、誰が、いつ、どのリポジトリに対して、どの操作をしたかを確認します。
- 可視性を変更したアカウントと時刻。
- 直前・直後の管理者権限やメンバー変更。
- GitHub App、OAuth App、Deploy key、Webhookの追加・変更。
- Actions、Environment、secret、rulesetの変更。
- 不審なアカウント操作や、通常と異なる管理経路。
監査ログで確認できるのはGitHubが記録するイベントです。公開期間中に外部の誰も閲覧・複製していないことまで、監査ログだけで証明できるとは限りません。確認できた事実と確認できない範囲を分けて記録します。
初動対応：確認後に進めること
影響拡大を止める
- リポジトリと関連する公開サーフェスを限定する。
- 有効なシークレットを失効する。
- 誤操作ではなく不正な権限変更が疑われる場合は、該当アカウントとセッションも確認する。
- 影響を受けるCI/CDやサービスに、一時的な制限が必要か判断する。
証跡を保全する
- 公開開始と発見・非公開化の時刻。
- 可視性変更、権限変更、シークレット変更に関する監査ログ。
- Secret Scanningアラート、通知、対応チケット。
- 影響を受ける外部サービスの認証・操作ログ。
- 担当者、判断、実施時刻、未確認事項。
証拠保全が必要な組織では、保管場所、取得者、取得時刻、原本と作業用コピーを区別します。
履歴とコピーを整理する
GitHub公式ドキュメントでは、機密情報を履歴から取り除く作業には、履歴の書き換え、GitHub上の参照、共同作業者のclone、fork、Pull Request、キャッシュなどの調整が伴うと説明されています。履歴を変更すると共同作業へ副作用が出るため、影響範囲と担当者を決めてから公式手順を使います。
特に重要なのは次の2点です。
- シークレットは履歴整理前に失効する。
- Public forkや第三者のcloneは、元リポジトリをPrivateへ戻しただけでは回収できない場合がある。
個人情報や高リスクの機密情報が第三者リポジトリに残るなど、自組織だけでは除去できない場合は、GitHub Supportの公式窓口と社内の法務・プライバシー担当へ相談します。
やってはいけないこと
- 記録や影響確認をせず、リポジトリを削除して対応完了にしない。
- 有効なシークレットを残したまま、履歴の書き換えだけを先に行わない。
- 「数分だけだった」「starsやforkがない」という理由だけで、閲覧・複製されていないと断定しない。
- 公開されていた認証情報を、動作確認のために実行しない。
- 影響が分からないまま全ブランチを強制更新し、共同作業や証跡を壊さない。
- 顧客・従業員情報を含む可能性があるのに、開発チームだけでクローズしない。
- 調査対象URLや機密情報を、公開Issueや通常のチャットへ再掲しない。
判断基準：危険度とエスカレーション
| 優先度 | 条件 | 推奨する判断 |
|---|---|---|
| 緊急 | 本番で有効なシークレット、秘密鍵、クラウド・決済・顧客環境の認証情報が含まれる | 即時失効、関連サービスのログ確認、CSIRT・責任者へ報告 |
| 緊急 | 顧客・従業員の個人情報、契約上の機密情報、規制対象データが含まれる | 非公開化と証跡保全を行い、法務・プライバシー・経営判断へ接続 |
| 高 | 未公開コード、内部構成、運用手順、Actionsログや成果物が公開された | 悪用可能性、公開期間、fork・コピー、関連防御設定を評価 |
| 高 | 可視性変更に心当たりがない、管理者権限やGitHub Appの変更もある | アカウント侵害の可能性として認証・権限・監査ログを拡大確認 |
| 中 | 機密情報や有効なシークレットは確認されず、公開範囲が限定的 | 判断根拠を記録し、履歴と周辺機能を再確認して再発防止へ進む |
| 低 | 公開前提のコードのみで、情報所有者が確認済み | 誤公開経路と設定不備を記録し、可視性変更ルールを改善 |
重大度は公開時間だけで決めません。情報の機密性、認証情報の有効性、権限、外部コピーの可能性、関連システムへの波及を組み合わせます。判断できない項目は「影響なし」にせず、未確認として期限と担当者を設定します。
記録テンプレート
対象Organization／所有者:
対象リポジトリ:
本来の可視性:
発見時の可視性:
発見日時・発見者:
公開開始日時（確認済み／推定）:
非公開化日時・実施者:
公開されていたブランチ・タグ・周辺機能:
含まれていた情報の分類:
認証情報の種類・発行元・失効日時:
Secret Scanningアラート:
fork・clone・ミラーの確認結果:
監査ログで確認した操作:
関連サービスで確認したログ:
保全した証跡と保管場所:
影響を受ける可能性がある利用者・顧客:
報告先・担当者:
未確認事項・確認期限:
復旧・再発防止の完了条件:記録は「確認済み」「推定」「未確認」を分けます。公開開始時刻や外部コピーの有無が確定できない場合は、断定せず調査範囲と判断根拠を残します。
よくある誤解
「Privateへ戻せば、公開中のforkもPrivateになる」
GitHub公式ドキュメントでは、PublicからPrivateへ変更した場合、Public forkは切り離され、Publicのまま残ることがあると説明されています。元リポジトリの現在の表示だけで、外部コピーがなくなったとは判断できません。
「最新のファイルから削除すれば履歴からも消える」
通常のファイル削除は、過去のコミット、PR参照、fork、clone、キャッシュまで自動で消すものではありません。機密情報を履歴から整理する必要がある場合は、GitHub公式手順を確認し、共同作業者と影響を調整します。
「履歴を書き換えればシークレットは安全になる」
履歴の変更は、すでに複製されたシークレットを無効化しません。最初に発行元で失効し、新しい認証情報へ切り替えます。
「Secret Scanningがあるので、漏えいはすべて検出できる」
Secret Scanningは重要な検知手段ですが、対象となるパターン、設定、リポジトリ種別、独自形式の情報によって検出範囲が異なります。アラートがないことだけで、シークレットや機密情報がないと断定しません。
「公開時間が短いので報告しなくてよい」
短時間でも、有効な認証情報や機密性の高いデータが含まれていれば優先度は上がります。時間は判断材料の一つであり、情報分類と影響範囲を先に確認します。
再発防止：公開前に止める仕組み
- Organizationで可視性を変更できる役割を必要最小限にする。
- 新規リポジトリの標準可視性と、Public化の承認手順を決める。
- Push ProtectionとSecret Scanningを利用可能な範囲で有効化し、バイパス理由をレビューする。
- 本番の認証情報をリポジトリへ保存せず、承認済みのシークレット管理へ分離する。
- OSS公開前のチェックに、履歴、Issue、PR、Actions、Release、ライセンス、個人情報を含める。
- 監査ログの保管、通知、定期レビューの担当者を決める。
- 誤公開を見つけた人が責められず、すぐ報告できる窓口を用意する。
GitHub Enterprise Cloudでは、Organization ownerが可視性変更権限を制限できます。設定だけに依存せず、Public化の目的、承認者、公開前確認、戻し方を運用として明文化します。
関連用語・関連ページ
| 次に確認すること | CyberLensのページ |
|---|---|
| 認証情報を失効・更新する | GitHub secret leak対応チェックリスト、GitHubトークン漏えい対応テンプレート |
| Secret Scanningアラートを処理する | GitHub Secret Scanningアラート初動対応 |
| 署名用secretの影響を確認する | Webhook署名シークレット漏えい時の初動対応 |
| 事故対応の基本を学ぶ | インシデントレスポンス入門、リスク・脅威・脆弱性の違い |
| 関連概念を確認する | データ分類、インシデント対応、証拠保全 |
| 用語の理解を定着させる | セキュリティ用語クイズ |
公式情報・参考情報
- GitHub Docs: Setting repository visibility - Public、Private、Internalの変更方法と、フォークやActionsログなど可視性変更時の影響。
- GitHub Docs: Removing sensitive data from a repository - 認証情報の失効を先に行い、履歴、fork、clone、PR参照、キャッシュを整理する際の注意点。
- GitHub Docs: Reviewing the audit log for your organization - Organizationで誰が、何を、いつ操作したかを確認・出力する公式ガイド。
- GitHub Docs: Secret scanning - Git履歴や関連サーフェスに含まれる認証情報の検知とアラート後の対応。
- GitHub Docs: Push protection - 認証情報を含むpushを保存前にブロックし、例外を管理する仕組み。
- GitHub Enterprise Cloud Docs: Restricting repository visibility changes - 可視性を変更できる担当者をOrganizationで制限する設定。
- NIST SP 800-61 Rev. 3: Incident Response Recommendations and Considerations - 検知、対応、復旧をサイバーセキュリティリスク管理へ組み込む指針。
まとめ
GitHubリポジトリを誤って公開した場合は、非公開へ戻した時点を対応の始まりと考えます。検知時刻と対象を記録し、シークレットを失効し、履歴、ブランチ、PR、Issue、Actions、fork、監査ログ、関連サービスを確認します。
公開中の閲覧や複製を完全に証明できない場合もあります。確認できた事実、推定、未確認を分け、情報の機密性と認証情報の有効性を基準にエスカレーションしてください。最後に、可視性変更権限、公開前レビュー、Secret Scanning、Push Protection、報告手順を見直し、同じ誤公開を早く止められる運用へつなげます。
