開発会社から「御社のサーバーのパスワードが、公開されているリポジトリ（＝プログラムの保管場所）に載っていたことが分かりました。すでに変更しました」と報告を受けたら、驚くのは当然です。「変えたなら終わりなのか」「もう悪用されていないか」と不安になる方が多いと思います。
「パスワードが公開リポジトリに載っていたと言われた。パスワードを変える以外に、何をすればいいんだろう？」
先に結論をお伝えします。パスワードの変更は、対応の入口にすぎません。 変更が済んだあとに、発注者として確認したいのは「いつからいつまで公開されていたか」「その間に使われた形跡はないか」「同じパスワードを他でも使っていないか」「再発を防ぐ仕組みが入ったか」の4点です。この記事では、この4点に報告・記録を加えた5つの確認を、開発会社への質問例とチェックリストとともに説明します。
なお、この記事は一般的な考え方の紹介です。個人情報の漏えいが疑われる場合の届出や、契約上の責任の判断は、弁護士や専門家、公式の窓口に確認してください。
パスワードが公開リポジトリに載っていた、とはどういう状態か
リポジトリ（＝プログラムやその変更履歴を保管する場所）は、開発会社が作業のために使うものです。GitHub（＝プログラムの共有サービス）のようなサービスでは、誰でも見られる「公開」と、許可された人だけが見られる「非公開」を選べます。
パスワードやAPIキー（＝外部サービスを使うための合言葉のようなもの）のようなシークレット（秘密情報）が、設定ファイルやプログラムの中にそのまま書かれたまま、公開のリポジトリに置かれてしまうことがあります。原因の多くは作業ミスで、悪意があったとは限りません。たとえばテスト用に書いたものを消し忘れた、設定ファイルをまとめて保管してしまった、といったものです。
GitHub の公式ドキュメントは、漏えいしたシークレットについて、すぐに悪用される可能性があるものとして扱うよう求めています。
📰 出典：GitHub Docs「Remediating a leaked secret」
公式ドキュメントでは、コードから消す・新しいコミット（＝変更の記録）を追加する・リポジトリを削除して作り直す、といった対応だけでは悪用を防げないと説明されています。サービスの提供元で、そのパスワードやキーを無効化または入れ替える（ローテーション）ことが最優先です。ここまでは、開発会社がすでにやってくれた、という報告が多いでしょう。問題はその先です。
「変えたので大丈夫です」の先に、発注者が確認すべき理由
パスワードを変えれば、これから先の悪用は防げます。しかし、変える前に使われていなかったかは、別に調べないと分かりません。
公開されていた時間が長いほど、第三者に見られた可能性は高くなります。一方で、公開されていた時間が数分でも、自動で探すプログラムに拾われる場合があると言われます。「短時間だったから大丈夫」とは言い切れないため、使われた形跡があったかどうかを、記録（ログ）で確かめることになります。
ここで気をつけたいのは、開発会社を責める進め方にしないことです。作業ミスは、人が作業する限りゼロにはできません。大切なのは、起きたあとの調べ方と、再発を防ぐ仕組みが整っているかです。落ち着いて、順番に確認していきましょう。
パスワードを変える以外にやる5つの確認
1. 公開されていた期間と、載っていた情報の範囲を確かめる
最初に、事実を整理します。「いつ、どのリポジトリに、何が載ったか」が分からないと、以降の調査の範囲が決まりません。
- 公開されたのはいつからか（変更の記録＝コミットの日時で分かります）
- 公開が止まったのはいつか（非公開にした、または削除した日時）
- 載っていたのは何か（サーバーのパスワードか、データベースのパスワードか、外部サービスのAPIキーか）
- 同じファイルに、ほかの情報（お客様のデータ、個人情報、別のサービスのキー）は含まれていなかったか
「パスワードが1つ載っていた」と聞いても、実際には複数載っていることがあります。一覧にして書面で受け取ることをおすすめします。
2. 公開されていた期間に、不審な使われ方がなかったかをログで確かめる
次に、その期間にパスワードが使われた記録を調べます。サーバーへのログイン記録、データベースへの接続記録、クラウドサービスの操作記録（AWS なら CloudTrail＝操作の履歴を残す機能）が材料になります。GitHub の公式ドキュメントも、漏えいしたシークレットの利用履歴を提供元の監査ログで確認するよう案内しています。
見るポイントは次のようなものです。
- 普段使わない場所（国・アドレス）や時間帯からのログイン
- 公開期間中に増えた、見覚えのない操作（ユーザーの追加、データの大量取得など）
- 設定の変更（権限の追加、新しいキーの発行など）
ログが残っていない、または保存期間が短くて確認できない場合は、そのこと自体を記録に残してください。 「不正利用の形跡は見つかっていない」と、「調べられなかった」とでは意味が違います。報告書では、この2つを分けて書いてもらいましょう。
3. 同じパスワードやキーを、ほかで使い回していないか確かめる
漏れたのが1つのパスワードでも、同じものを別のサーバーや別のサービスでも使っていると、被害が広がります。次の点を開発会社に確認します。
- 同じパスワードを、本番環境とテスト環境で共用していなかったか
- そのパスワードで入れる範囲（権限）は、必要以上に広くなかったか
- 変更した新しいパスワードは、古いものと無関係に作られているか（一部だけ変えたものになっていないか）
特に、本番のデータに触れられるパスワードが漏れていた場合は、データベースに入っている情報の種類（個人情報の有無など）の確認が必要になります。
4. 履歴に残った情報と、コピーが残る可能性を理解する
「ファイルを消したので、もう見えません」という説明を受けることがあります。しかし GitHub のドキュメントによると、履歴を書き換えて消した場合でも、他の人が作ったコピー（クローン、フォーク）や、GitHub 上のキャッシュ表示、そのコミットを参照するプルリクエスト（＝変更の取り込み依頼）には、情報が残り得るとされています。
📰 出典：GitHub Docs「Removing sensitive data from a repository」
このため、履歴からパスワードを消す作業は、あくまで補助的なものです。消したから安心、ではなく、パスワードの無効化が済んでいることが本当の安心につながります。 履歴を書き換える作業には、変更の記録の番号が変わる、他の作業者の手元の記録と食い違うなどの副作用もあります。やるかどうかは、開発会社と相談して決めましょう。
5. 再発を防ぐ仕組みを入れてもらう
最後に、同じことが起きないようにする仕組みの確認です。「今後は気をつけます」という言葉だけでは足りません。仕組みで防げているかを聞きます。
- プッシュ保護（push protection）：パスワードのような文字列を含む変更を、リポジトリに送る（プッシュする）時点で止める機能。GitHub などに用意されています
- シークレットスキャン：リポジトリの中に秘密情報が紛れていないかを自動で探す機能
- 秘密情報の置き場所の分離：パスワードをプログラムの中に書かず、環境変数（＝プログラムの外から渡す設定値）や、シークレットを管理する専用のサービスから読み込む形にする
- 定期的な入れ替え：パスワードやキーを一定期間で入れ替えるルール
- AIコーディングツールの設定ファイルの確認：AI ツールが作る設定ファイルに、パスワードが書き残されることがあります。共有する場所に置かれていないかを確認する
どれも、一度入れておけば、人の注意力に頼らず守れる仕組みです。費用や作業量は仕組みによって違うため、見積もりの要否も含めて確認してください。
やりがちな失敗
漏えいの報告を受けたあとに起こりがちな失敗を、3つ挙げておきます。
- パスワードを変えただけで報告を終える：調査（ログの確認）と再発防止の記録が残らず、後から「あの時どうだったか」を説明できなくなります
- 責任の追及を先にしてしまう：原因の聞き取りが進まなくなり、調査が遅れます。事実の確認が先、責任の話は事実がそろってからにしましょう
- 発注者側のパスワードの使い回しを見落とす：開発会社が管理していないところ（社内の別システムなど）で同じパスワードを使っていないか、自社側も確認が必要です
発注者がやること チェックリスト
- ☐ 公開されていた期間（開始と終了の日時）を、書面で受け取った
- ☐ 載っていた情報の一覧（パスワード、APIキー、個人情報など）を受け取った
- ☐ 公開期間中のログを確認し、その結果（不審なアクセスの有無、または確認できなかったこと）を報告してもらった
- ☐ 同じパスワード・キーの使い回しがないか確認してもらった
- ☐ 古いパスワード・キーが提供元で無効になっていることを確認した
- ☐ 履歴の消去を行うかどうか、行う場合の影響を説明してもらった
- ☐ プッシュ保護やシークレットスキャンなど、再発防止の仕組みの導入予定を確認した
- ☐ 個人情報が含まれていた可能性がある場合、専門家や公式の窓口に相談した
開発会社への質問例
そのまま打ち合わせで使える質問を並べます。責める口調にならないよう、「確認させてください」という形にしています。
- 「公開されていた期間は、いつからいつまででしたか。その根拠となる記録を見せてもらえますか」
- 「その期間のログを確認して、不審なアクセスがなかったか教えてください。ログが残っていない部分があれば、その範囲も教えてください」
- 「漏れたパスワードやキーは、ほかの環境やサービスでも使われていましたか。入れ替えはすべて済んでいますか」
- 「リポジトリの履歴や、コピーが残る可能性についてはどう考えていますか。履歴を消す場合の影響も教えてください」
- 「再発を防ぐために、プッシュ保護やシークレットスキャンなどの仕組みを導入できますか。作業量と費用の目安も教えてください」
まとめ
- パスワードの変更は、漏えい対応の入口です。変更しても、変更前に使われた可能性は別に調べる必要があります
- 発注者が確認したいのは、公開期間と範囲、ログでの使用形跡、使い回しの有無、履歴とコピーの扱い、再発防止の仕組みの5つです
- 「使われた形跡なし」と「調べられなかった」は別の話です。報告書では分けて書いてもらいましょう
- 開発会社を責めるより、事実の整理と仕組みづくりを先に進めるほうが、結果として被害を小さくできます
漏れた情報が「APIキー」の場合は、入れ替えの順番や所要日数の考え方が少し変わります。詳しくは次の記事で解説しています。
あわせて読みたい関連記事
