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

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

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

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

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

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

事故後によくある誤解が、「ファイルを消した」「リポジトリ を private にした」ので終わり、というものです。しかし現実には、過去 commit、branch、tag、release artifact、fork、clone、issue のスクリーンショット、PR見直しcomment、wiki の手順書、公開ドキュメント に同じ secret が残っていることがあります。どの面に複製されたか分からない状態こそが危険です。

そのため公開リポジトリ事故は、単なる code hygiene ではなく、evidence台帳と 是正対応 流れ の問題として扱う方が実務に合います。まず影響 秘密情報を棚卸しし、次にどの公開面へ残っているかを洗い、最後に rotate、revoke、history 除去対応、再発防止へ戻す流れを持つ必要があります。

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

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

GitHub Docs のRemediating a leaked secret↗は、leaked secret の 是正対応 を 履歴書き換え の話から始めていません。先にやるべきは、その secret が今も使えるかを止めることです。token、password、API key、credential が生きたままでは、たとえ commit を消しても被害は止まりません。

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

fork、clone、tag、release artifact は別経路で残る

リポジトリ の 現在のブランチ から file を消しても、fork や clone は別です。これは GitHub 固有というより Git の性質ですが、公開済み リポジトリ は複製前提で広がります。元 リポジトリ から消しても、fork 済み repository、古い tag、release に添付した artifact、CI artifact などに残っていれば、事故の文脈は続きます。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

そのうえで GitHub は リポジトリ 以外の面も 検知対象に持てるため、リポジトリ の tree だけを見て 完了 すると甘くなります。検知通知見直しでは、supported secret の種類だけでなく、どの surface に残ったかも意識して triage する必要があります。

GitLab は pipeline detection と 自動対応 を組み合わせる

GitLab Docs のPipeline secret detection↗とAutomatic response to leaked 秘密情報↗は、detection を CI / pipeline の流れへ組み込み、leaked secret に対して response を返す考え方を示しています。GitLab 側で完結するというより、漏えいを見つけたあとにどこまで response を自動化するかを決める運用です。

注意点は、pipeline を通る repository 面が中心になりやすいことです。したがって GitLab でも、issue、docs、外部 wiki、artifact、公開した サンプル設定 などの周辺面は別観点で残存確認が必要です。platform 機能だけに 是正対応 全体を寄せない方が安全です。

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

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

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

最初の 24 時間で重要なのは、使える credential を止めることです。rotate / revoke、提供先 側 監査ログ 確認、affected管理責任者連絡、必要なら temporary kill switch を進めます。同時に、GitHub push時の漏えい防止 や GitLab detection を有効化して同じ 種類 の漏えいを追加で流さない状態にします。

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

次の数日は 除去対応台帳が主役です。history、fork、tag、release artifact、issue、PR、wiki、公開ドキュメント、サンプル設定 を洗い、「削除」「編集」「管理責任者連絡」「monitoring 継続」のどれに回すかを決めます。ここを一覧にせずに個別対応すると、完了 条件が曖昧なまま残りやすくなります。

8-30日で 見直し頻度 と docs hygiene を固定する

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

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

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

たとえば leaked config に書かれていた公開ドキュメント用ホスト、staging URL、admin path、storage export URL、古い subdomain は、source 側を直しても インターネット から到達できる形で残ることがあります。そこで未管理資産リスクやアタックサーフェスの観点で、外部観点の現状確認を入れる意味があります。

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

よくある質問（FAQ）

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

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

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

完了ではありません。history、fork、issue、PR、wiki、release artifact、公開ドキュメント に同じ secret が残ることがあるためです。current リポジトリ の 公開設定 変更は一部の対処であって、完了 条件そのものではありません。

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

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

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

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

最初の 1 か月で何を done にすべきですか

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

まとめ

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

• 履歴書き換え より先に leaked 秘密情報を止める
• fork、issue、PR、wiki、docs を残存面台帳に入れる
• GitHub は detection と push時の漏えい防止 を両輪で使う
• GitLab は detection と 自動対応 を運用へ組み込む

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