公開リポジトリの情報漏えいとは？GitHub・GitLab の秘密情報露出と対処フロー

公開リポジトリの情報漏えいとは何か

「ソースコード漏えい」ではなく開発資産の外部露出として見る

公開リポジトリ事故は、単純にソースコードが見えた、という話だけではありません。問題になるのは、設定ファイル、デプロイスクリプト、公開ドキュメント、サンプルリクエスト、出力ファイル、対応メモまで含めて、開発資産がインターネット上のどこへ露出したかを把握できなくなることです。DRPSが 漏えいした認証情報 の外部悪用監視を主役にするのに対して、本記事は開発資産そのものの公開面を主役に据えます。

特に GitHub では、秘密情報の自動検知↗が リポジトリ だけでなく、issues、プルリクエスト、discussions、wiki に含まれる対応対象の秘密情報も対象にできます。つまり「リポジトリ の ツリー にないから大丈夫」という発想では不足します。貼り付け、議論、運用メモまで含めて、どこへ秘密情報が広がったかを見る必要があります。

危険なのは「現在のファイル」より「残存した複製と文脈」

事故後によくある誤解が、「ファイルを消した」「リポジトリ を非公開にした」ので終わり、というものです。しかし現実には、過去コミット、ブランチ、タグ、リリース添付物、フォーク、複製、issue のスクリーンショット、PR見直しコメント、wiki の手順書、公開ドキュメント に同じ秘密情報が残っていることがあります。どの面に複製されたか分からない状態こそが危険です。

そのため公開リポジトリ事故は、単なるコード運用の衛生管理ではなく、証跡台帳と 是正対応 の流れ の問題として扱う方が実務に合います。まず影響する秘密情報を棚卸しし、次にどの公開面へ残っているかを洗い、最後に再発行、失効、履歴の除去対応、再発防止へ戻す流れを持つ必要があります。

とくに検索でこのテーマにたどり着く読者は、「うっかり上げた秘密情報をどう消すか」よりも、どこまで残っているか分からない不安を抱えていることが多いはずです。その不安に答えるには、現在のリポジトリ だけを見るのでは不十分です。履歴、配布物、議論ログ、公開ドキュメントを同じ事故の残存面として扱い、外へ広がった範囲を説明できる状態へ戻す必要があります。ここまで見えて初めて優先順位が付きます。

なぜ「削除した」「非公開に戻した」だけでは終わらないのか

履歴書き換え より先に 無効化 / 再発行 が必要になる

GitHub Docs の漏えいした秘密情報への対処↗は、漏えいした秘密情報 の 是正対応 を 履歴書き換え の話から始めていません。先にやるべきは、その秘密情報が今も使えるかを止めることです。トークン、パスワード、APIキー、認証情報 が生きたままでは、たとえコミット を消しても被害は止まりません。

現場では「Git の履歴から消す作業」が目立ちますが、順序を間違えると危険です。まず 無効化 / 再発行、必要なら 提供先 側の 監査ログ 確認、影響範囲 の整理、その後に履歴の除去対応 やドキュメント修正へ進むのが基本です。除去対応 は重要ですが、初動の代わりにはなりません。

フォーク、複製、タグ、リリース添付物 は別経路で残る

リポジトリ の 現在のブランチ からファイルを消しても、フォーク や複製 は別です。これは GitHub 固有というより Git の性質ですが、公開済み リポジトリ は複製前提で広がります。元 リポジトリ から消しても、フォーク 済みのリポジトリ、古いタグ、リリース に添付した成果物、CI 成果物 などに残っていれば、事故の文脈は続きます。

そのため 是正対応 では、現在のツリー の修正だけでなく、どこへ複製されたかを台帳化しなければなりません。ここを飛ばすと、「本体は直したのに外から拾える面が残っている」状態になりやすくなります。

issue、PR、wiki、公開ドキュメント のコピペが長く残りやすい

GitHub 秘密情報の自動検知 が issues、プルリクエスト、discussions、wiki まで対象を広げているのは、そこが現実に事故面になるからです。障害対応の貼り付け、PR見直し用の サンプルリクエスト、wiki に書いた セットアップ 手順、公開ドキュメント に残った 例 などは、開発者自身が コード とは別物として扱いやすく、除去対応 が遅れます。

つまり公開リポジトリ事故は、「リポジトリ のファイル を直す」だけの話ではなく、リポジトリ 周辺の説明文や運用メモまで含めた 除去対応を要する事故です。ここを 確認項目 に入れておかないと、秘密情報の自動検知 検知通知 を 完了 しても再発します。

最初に確認すべき5つのポイント

1. 影響 秘密情報を「種類・権限・接続先」で切る

漏えいした 秘密情報を「何か鍵が出た」程度で扱うと 是正対応 は進みません。必要なのは、トークン の種類、権限、接続先 サービス、管理責任者、再発行 手順、ログ確認先です。クラウド認証情報、SaaS用トークン、パッケージレジストリ用トークン、デプロイ鍵、Webhook用秘密情報 は影響範囲が違います。まず何がどこへ効くかを固定してください。

2. リポジトリ 本体と周辺公開面を分けて台帳する

是正対応 では、リポジトリ本体、履歴、フォーク、issue / PR、wiki、公開ドキュメント、成果物 を同じ箱で数えない方が運用しやすくなります。リポジトリ 本体の 除去対応 と、周辺公開面の 除去対応 では管理責任者も手順も違うからです。ここは残存面 台帳として分けた方が会話が速くなります。

3. 監査ログと 検知通知見直しを同時に見る

再発行 して終わりにしない理由は、すでに利用された可能性があるからです。提供先 側の 監査ログ、GitHub / GitLab の 検知通知、トークン 最終利用 情報、想定外のIP や 操作 を確認し、単なる予防 除去対応 なのか、事案対応 なのかを分ける必要があります。

4. 秘密情報の自動検知 を「有効化したか」ではなく「どこまで見ているか」で見る

検知機能 は チェック項目 ではありません。GitHub なら リポジトリ だけでなく issue / PR / wiki まで 検知対象に入っているか、push時の漏えい防止 が 阻止 できる状態かを確認します。GitLab なら パイプラインの秘密情報検知 をどこで回し、自動対応 をどこまで使うかを決める必要があります。

5. 再発防止は リポジトリ 運用だけでなく公開ドキュメント 運用まで戻す

秘密情報が残りやすいのは コードファイル だけではありません。設定手順書、サンプルcurl、Issueテンプレート、サポート用wiki、migration 手順書も事故面です。再発防止は リポジトリ運用の衛生管理 だけでなく、公開ドキュメント と運用メモの 見直し頻度まで戻して初めて閉じやすくなります。

GitHub・GitLab で何を検知し、どこまで自動化できるか

GitHub は検知と push時の漏えい防止 を両輪で使う

GitHub ドキュメント の秘密情報の自動検知とは↗とpush時の漏えい防止とは↗を合わせて読むと、GitHub の考え方は明確です。漏えい後に見つける 検知 と、push 前に止める 事前防止 を分けて持つことです。特に push時の漏えい防止 は「レビューで気付く」ではなく、push の瞬間に 阻止 するので、同種事故の再発抑止に効きます。

そのうえで GitHub は リポジトリ 以外の面も 検知対象に持てるため、リポジトリ の ツリー だけを見て 完了 すると甘くなります。検知通知見直しでは、対応対象の秘密情報の種類だけでなく、どの公開面に残ったかも意識して優先度付けする必要があります。

GitLab は パイプライン検知 と 自動対応 を組み合わせる

GitLab ドキュメント のパイプラインの秘密情報検知↗と漏えいした秘密情報への自動対応↗は、検知 を CI / パイプライン の流れへ組み込み、漏えいした秘密情報 に対して対応を返す考え方を示しています。GitLab 側で完結するというより、漏えいを見つけたあとにどこまで対応 を自動化するかを決める運用です。

注意点は、パイプライン を通る リポジトリ面 が中心になりやすいことです。したがって GitLab でも、issue、ドキュメント、外部 wiki、成果物、公開した サンプル設定 などの周辺面は別観点で残存確認が必要です。プラットフォーム機能だけに 是正対応 全体を寄せない方が安全です。

ここを取り違えると、「GitHub や GitLab の機能を有効化したから収束した」と誤認しやすくなります。実際には、プラットフォーム機能は見つける・止める・通知するところまでは強い一方で、外へ広がった断片を誰が回収するかまでは決めてくれません。だからこそ、公開リポジトリ事故では機能有効化と残存面台帳を必ずセットで持つ必要があります。

見落としやすい周辺公開面をどう洗うか

リリース添付物、パッケージ配布物、成果物置き場に同じ秘密情報が残る

公開リポジトリ事故で見落としやすいのが、リリース添付物やパッケージ配布物です。ソースコードから秘密情報を消しても、配布用 zip、設定見本、ビルド済み成果物、CLI のサンプル設定が別面に残っていれば、利用者や第三者はそこから同じ情報を拾えます。ソース本体の修正だけでは公開面の除去になりません。

とくに GitLab のパッケージレジストリ や generic packages のような配布面、GitHub release に載せた成果物、検証用に外部へ渡した build 物は、リポジトリの公開設定を変えても別系統で生き残ることがあります。是正対応では、コード、配布物、サンプル設定、公開導線を同じ台帳で横に並べて追うことが必要です。

issue、PR、wiki、障害メモは『直したつもり』の外側に残りやすい

もう一つ厄介なのが、障害対応の議論や運用メモです。issue、PR、wiki、discussions、レビューコメント、移行手順書には、設定値や接続先 URL、暫定トークン、検証用認証情報が貼られやすくなります。GitHub の秘密情報検知がこうした面まで対象に広げられているのは、事故がファイル以外へ広がりやすいからです。

実務では、リポジトリ管理者とアプリ担当だけでなく、サポート、SRE、委託先、セキュリティ窓口が別々に記録を持っています。この分断を前提に、「どの面に何が残り得るか」の一覧を作らないと、修正済みのつもりで危険な断片だけが外に残ります。

履歴書き換えのあとは『再汚染』を止める運用が必要になる

GitHub ドキュメント が機微情報除去の副作用として強く警告しているのが、古い複製から秘密情報が戻る再汚染です。履歴を書き換えた後に、古い複製を持つ利用者がそのまま pull と push を行うと、除去したはずの情報が再度入り込む危険があります。これは技術的な除去対応の成否だけでなく、周知と手順の問題です。

そのため、履歴書き換えを実施するなら、関係者へ複製の扱い、強制 push 後の手順、開いているブランチや PR の扱い、再取得の期限を明示する必要があります。是正対応の完了条件は「filter-repo による除去 が終わったこと」ではなく、再び同じ情報が戻らない運用へ切り替わったことです。

ここで抜けやすいのが、周辺チームへの周知です。開発者だけでなく、サポート、技術営業、委託先、ドキュメント担当が古い複製や手順書を持っていると、善意で再掲した情報が再露出の起点になります。履歴書き換え後は、誰が古い複製を持っているかを洗い、再利用を止める連絡まで含めて完了条件を置く必要があります。

さらに、再汚染対策ではどの時点の複製を破棄対象にするかを明示しないと混乱します。古いローカル複製、検証環境に残るミラー、委託先へ配布した zip、社内ポータルへ貼られた手順書のどこまでを差し替えるかを決めておくと、除去対応後の運用が安定します。ここまで整理して初めて、秘密情報を削除したという説明が現実に近づきます。

漏えい時の 是正対応 フロー

是正対応 の難しさは、「再発行 だけでは足りないが、履歴書き換え だけでも足りない」ことです。以下の 30 日プランは、GitHub / GitLab の 検知機能 を前提にしつつ、公開面 除去対応 と再発防止を両立させる最小構成です。

0-24時間で 秘密情報を止め、新しい露出を 阻止 する

最初の 24 時間で重要なのは、使える認証情報を止めることです。再発行 / 失効、提供先 側 監査ログ 確認、影響を受けた管理責任者への連絡、必要なら一時停止措置を進めます。同時に、GitHub の push 時点の漏えい防止 や GitLab の検知機能 を有効化して同じ 種類 の漏えいを追加で流さない状態にします。

2-7日で残存面台帳を作る

次の数日は 除去対応台帳が主役です。履歴、フォーク、タグ、リリース添付物、issue、PR、wiki、公開ドキュメント、サンプル設定 を洗い、「削除」「編集」「管理責任者連絡」「継続監視」のどれに回すかを決めます。ここを一覧にせずに個別対応すると、完了 条件が曖昧なまま残りやすくなります。

この台帳では、残したまま監視する面と完全に除去する面を分けておくと実務で回しやすくなります。履歴や外部複製 のように即時削除し切れない面まで一律に扱うと、完了判定が止まります。是正対応を前に進めるには、面ごとの処置方針を先に定義することが重要です。

完了条件を面ごとに持つだけでも、是正対応の遅れはかなり減らせます。

処置方針の固定は、公開面の除去対応の速度を上げます。

8-30日で 見直し頻度 とドキュメント衛生 を固定する

最後の 3 週間では、再発防止を リポジトリ 運用に戻します。push 時点の漏えい防止、パイプラインの秘密情報検知、自動対応、見直し 確認項目、サンプル秘密情報 の禁止、公開ドキュメント見直しを固定し、月次見直しで新規 検知通知 と例外を観測します。事案の後始末ではなく、通常運用へ戻すためのルール化まで進めるのが重要です。

公開リポジトリの 秘密情報 対策なら ASM診断 PRO

ASM診断 PRO は GitHub / GitLab の秘密情報の自動検知やソースコード検査の代替製品ではありません。つまり、「リポジトリ内の秘密情報を検出して阻止する」主役はプラットフォーム側です。ただし、公開リポジトリ事故の後に現場で困るのは、リポジトリ由来の情報が外の公開面へどこまで波及していたかが見えないことです。

たとえば漏えいした設定ファイルに書かれていた公開ドキュメント用ホスト、検証環境 URL、管理画面パス、ストレージ出力URL、古いサブドメイン は、ソースコード側を直しても インターネット から到達できる形で残ることがあります。そこで未管理資産リスクやアタックサーフェスの観点で、外部観点の現状確認を入れる意味があります。

まず 公開診断で外から見えるホストと関連資産を洗い、そこから外部公開資産台帳や是正対応の課題一覧へ戻すと、「どの秘密情報がどの公開面に結び付いていたか」を整理しやすくなります。リポジトリ漏えいをコードの話だけで閉じず、公開面全体の 除去対応として扱うための入口として使ってください。

特に、リリース添付物、公開ドキュメント、旧検証環境、外部向け説明ページのようにコード修正後も残りやすい外部導線を洗えることに意味があります。リポジトリの除去対応 と公開面の除去対応 を別タスクにすると、最後に残る危険な断片を見落としやすくなります。

よくある質問（FAQ）

秘密情報の自動検知 を有効にすれば公開リポジトリ事故は防げますか

有効ですが、それだけでは足りません。自動検知 は重要ですが、push 時点の漏えい防止、見直し 確認項目、サンプル秘密情報の禁止、公開ドキュメント見直しまで揃えて初めて再発しにくくなります。事故後は残存面台帳も必要です。

リポジトリ を非公開に戻したら 是正対応 は完了ですか

完了ではありません。履歴、フォーク、issue、PR、wiki、リリース添付物、公開ドキュメント に同じ秘密情報が残ることがあるためです。現在のリポジトリの公開設定変更は一部の対処であって、完了 条件そのものではありません。

履歴書き換え は必ず必要ですか

状況次第ですが、少なくとも 無効化 / 再発行 より先に考えるべきではありません。使える 秘密情報を止めたうえで、履歴の除去対応 が必要な範囲を判断してください。履歴書き換え 自体が影響を持つため、管理責任者と利用者への周知も要ります。

issue や PR、wiki まで本当に確認すべきですか

はい。GitHub 秘密情報の自動検知 もそれらを対象に持っています。障害対応の貼り付けや設定手順のコピー は リポジトリのファイル以外に残りやすく、除去対応 が漏れる典型面です。

最初の 1 か月で何を完了条件にすべきですか

まずは、影響する秘密情報 一覧、残存面台帳、無効化 / 再発行 完了、push 時点の漏えい防止 または 自動検知 の有効化、月次見直しの固定化まで揃えば十分です。完璧な 除去対応 より、再露出を止めて管理責任者が説明できる状態を先に作る方が重要です。

まとめ

公開リポジトリの情報漏えいは、「リポジトリ に『.env』があった」だけの問題ではありません。危険なのは、過去コミット、フォーク、issue、PR、wiki、公開ドキュメント まで含めて、どこに秘密情報が残っているか説明できない状態です。だからこそ 是正対応 は、無効化 / 再発行と残存面 除去対応を分けて進める必要があります。

• 履歴書き換え より先に漏えいした秘密情報を止める
• フォーク、issue、PR、wiki、ドキュメント を残存面台帳に入れる
• GitHub は自動検知 と push 時点の漏えい防止 を両輪で使う
• GitLab は自動検知 と 自動対応 を運用へ組み込む

まずは影響する秘密情報 と残存面を一覧化し、リポジトリ漏えい を「単発のコード除去対応」ではなく「公開面全体の 是正対応」として扱ってください。そこからセキュリティレポート雛形や外部公開資産台帳へつなぐと、事故対応を運用へ戻しやすくなります。

公開リポジトリ事故を短く収束させるには、コード、配布物、議論メモ、公開ドキュメント、外部ホストを別々に扱わず同じ是正対応の対象として見ることが重要です。影響する秘密情報 の停止、残存面の台帳化、再汚染防止の周知までそろって初めて、同じ事故を繰り返しにくくなります。

とくにリリース添付物やパッケージ配布物を持つ開発組織では、ソースコードの除去対応より配布面の除去対応 の方が遅れやすいことを意識してください。公開リポジトリ事故は、開発チームだけの問題ではなく、配布、ドキュメント、外部公開面までまたぐ運用課題です。