GitHubのコミット履歴に全部書いてあった
SaaSの買収交渉で、対象企業のエンジニアから「ソースコードを見せます」という言葉をもらった瞬間に、私が最初に開くのはアプリケーションの動作確認でも、依存ライブラリの一覧でもありません。git log です。
コミットの日付をさかのぼり、git log -S "password" を走らせ、git log -S "secret" を叩く。財務系のDDが3週間かけて精査するIMの数字より、最初の15分で「この案件は安全か危険か」の輪郭が見えてくることが、現実にあります。AWSのシークレットキー、StripeのAPIキー、本番DBの接続文字列、会員3万人分のCSVファイル。これらは「削除した」と言われても、Gitのコミット履歴には永遠に残ります。買収後に第三者に悪用される可能性のある秘密情報が、譲渡対象のリポジトリの奥深くに眠り続けているケースを、私はこれまで複数回にわたって目撃してきました。
本記事は、ソースコードDDにおいて現役エンジニアが真っ先に確認する「Gitコミット履歴の発掘術」と、買い手・売り手の双方に存在する買収リスクの全貌を、実際のケースをもとに解説します。
1. なぜGitのコミット履歴が、M&Aにおける「最大の核」になるのか
1-1. バージョン管理の設計思想が「完全な変更履歴の永続保存」であるという原罪
Gitは、コードの「現在の状態」ではなく「すべての変更の歴史」を保存するために設計されたシステムです。コミットのたびに差分が記録され、git clone した時点でその全履歴がローカルに複製される。これは分散バージョン管理システムの根幹的な設計であり、それ自体は優れた思想です。しかしこの「完全な変更履歴の永続保存」という設計が、セキュリティの文脈では致命的な弱点に変わります。
開発初期に「とりあえず動かす」フェーズで雑にコミットされたAPIキー、デプロイ手順書がわりにREADMEへ書き込まれたDB接続情報、「後で消す」と思ったまま消し忘れられた秘密情報。これらはワーキングツリー上からは削除されたとしても、Gitの歴史の中に永遠に刻まれ続けます。
1-2. 財務DDは見ない、弁護士も見ない ── 誰もリポジトリに踏み込まない構造的空白
M&Aの一般的なDD工程において、ソースコードリポジトリに踏み込む専門家は誰もいません。仲介業者はIM作成と交渉まとめ、税理士・会計士は財務数字、弁護士は契約書の条項。「GitHubのリポジトリを開いてgit logを走らせる」という作業が、誰の標準工程にも組み込まれていないのです。
結果として、たとえ対象企業のリポジトリにAWSシークレットキーが埋まっていたとしても、技術者DDに本気の人間を入れていない買い手は、その存在を知らないまま譲渡を完了します。そして買収後に第三者に発見され、クラウドリソースが不正利用されて数百万円の請求が届いた時点で初めて、その爆弾の存在に気付く。
1-3. SaaSの事業価値を一夜で崩す秘密情報漏洩インシデントの連鎖
AWSシークレットキーが漏洩した場合の被害は即座に連鎖します。不正にEC2インスタンスを大量起動されてクラウド費用が跳ね上がる、S3バケット内の会員データが外部に流出する、RDSに直接接続されて会員情報が根こそぎ取得される。Stripeシークレットキーであれば、不正な課金・返金・サブスクリプション操作が外部から可能な状態が続きます。
買収後にこのようなインシデントが発生した場合、表明保証違反として売り手に損害賠償請求できる可能性はありますが、既に外部流出した個人情報は取り戻せません。個人情報保護委員会への報告義務、会員への通知、場合によっては業務停止処分。「買ったら地雷を踏んだ」という状況は、財務的な損失だけでは語れない規模の事態に発展します。
2. コミット履歴に眠る4種の時限爆弾 ── AWSキー・Stripeキー・DBパスワード・個人情報CSV
2-1. AWSアクセスキー・シークレットキー ── クラウド全リソースへの管理者権限が平文で残る
最も危険度が高く、かつ最も発見頻度が高い秘密情報がAWSのアクセスキー（AKIAIOSFODNN7EXAMPLE の形式で始まる20文字）とシークレットキーのペアです。これが漏洩した場合、攻撃者はそのIAMユーザーに与えられた権限を全て行使できます。管理者権限のキーであれば、EC2・S3・RDS・Lambda・IAMを含むクラウドインフラへの完全な読み書き権限が第三者の手に渡る。
コミット履歴の中でAWSキーを発見する頻度が高い理由は、開発初期フェーズで「とりあえずローカルの.envファイルに書いたつもりが、.gitignoreの設定前にコミットしてしまった」という失敗が極めて多いからです。GitHubにはAWSAccessKeyIdという文字列が含まれるコミットを自動検知する機能（Secret scanning）がありますが、プライベートリポジトリで無効化されていたり、検知後に対処せず放置されているケースが現実に存在します。
2-2. Stripeシークレットキー・決済APIキー ── 不正課金・払い戻し操作が第三者に可能な状態
sk_live_ で始まるStripeのシークレットキーが漏洩すると、そのStripeアカウントの全操作権限が第三者に渡ります。顧客の課金情報への参照、任意の決済の実行、返金処理の実行、サブスクリプションのキャンセル。コミット履歴の中に sk_live_ という文字列が残っていれば、それだけで買収後のSaaS事業において現実的な不正アクセスリスクが存在し続けます。
sk_test_ で始まるテスト用キーが残っているだけであれば被害は限定的ですが、テスト環境と本番環境で同じコードベースを使い回し、本番キーがどこかのコミットに混入しているケースは決して珍しくありません。
2-3. DBの接続文字列・rootパスワード ── 会員テーブルへの直接アクセス経路がそのまま放置
mysql://root:[email protected]:3306/production のような接続文字列がコミット履歴に残っている場合、外部から本番データベースへの直接アクセス経路が記録された状態が続いていることを意味します。もちろんセキュリティグループやVPC設定でアクセス元を制限している場合は外部からの直接接続は不可能ですが、「コミット履歴にDBパスワードが残っている」という事実は、そのパスワードが他の用途（内部管理ツール・バックアップスクリプト等）でも使い回されている可能性を示唆し、漏洩経路が複数存在するリスクを意味します。
2-4. 会員情報CSVの直コミット ── 個情法上の「漏洩」が記録として完成した瞬間
会員情報のCSVファイルがコミット履歴に残っているケースは、セキュリティ問題であると同時に個人情報保護法上の問題でもあります。「CSVを直接コミットしてテストデータを確認した」「バックアップ目的でリポジトリに含めた」という経緯で入り込んだ実名・メールアドレス・電話番号入りのCSVは、GitHubのプライベートリポジトリに存在している時点で、個人情報が適切に管理されていない状態の証拠となります。2022年の改正個人情報保護法施行以降、「不正アクセスによる漏洩」だけでなく「不適切な管理状態」も個人情報保護委員会の勧告対象になり得ます。買収後にこのCSVの存在が発覚した場合、それは売り手から受け継いだリスクとして買い手が引き受けることになります。
3. 「削除した」は通用しない ── git logが永遠に刻む変更の痕跡
3-1. git rm と git log の非対称性 ── ワーキングツリーから消えても、履歴には残り続ける
ソースコードに秘密情報が含まれていることに気づいた売り手が取りがちな行動が「git rmでファイルを削除してコミットする」です。これは完全に間違った対処法です。
git rm secrets.env && git commit -m "秘密情報を削除" を実行しても、削除する前のコミット（例えば3日前のコミット）には secrets.env の内容がそのまま保存されています。git checkout [3日前のコミットハッシュ] を実行すれば、削除済みのはずのファイルが完全な状態で復元できます。Gitにおける「削除」は「このファイルを今後のコミットから除外する」という宣言であり、過去の歴史は一切変更されません。
3-2. git log -S "AKIA" 1行で発掘されるAWSキー ── 現役エンジニアの実際の初手
現役エンジニアがソースコードDDで最初に実行するコマンドは以下のようなものです。
git log -S "AKIA" --all --oneline
git log -S "sk_live_" --all --oneline
git log -S "password" --all --oneline
git log -S "secret" --all --oneline
git log -S "token" --all --oneline
git log -S は「指定した文字列を追加または削除したコミット」を検索するPickaxeオプションで、どのコミットで問題の文字列が出入りしたかを一覧できます。これだけで、ほとんどの秘密情報の混入タイミングと対象コミットを特定できます。追加で git show [コミットハッシュ] を実行すれば、そのコミットの全差分が確認でき、漏洩した秘密情報の実体を特定できます。慣れたエンジニアならこの確認作業を15分で完了します。財務系DDチームが3週間かけて精査するIMの数字以上の情報が、15分で掘れることがあります。
3-3. forkした瞬間に履歴がコピーされるGitHubの構造 ── fork先での「生存」という追加の地獄
さらに問題を複雑にするのが、GitHubのfork機能です。外部の開発者がリポジトリをforkしていた場合、fork先には秘密情報を含むコミット履歴がそのままコピーされています。元のリポジトリでBFG Repo Cleanerを使って履歴を書き換えたとしても、fork先のリポジトリには元の汚染済み履歴が残り続けます。
プライベートリポジトリで外部コントリビューターにforkを許可していた場合、または過去に一時的にパブリックになっていた期間があった場合、その間にforkされたリポジトリを全て特定して対処することは事実上不可能です。GitHubはforkされたリポジトリの一覧をオーナーが確認できる仕様にはなっていますが、全員のfork先に書き換えを適用する手段はありません。
4. 買収交渉中に実際に発見される衝撃の3ケース
4-1. 【ケース1】2年前のコミットに残ったStripeシークレットキーが、DDの時点でまだ有効だった
SaaS事業の買収交渉で、売り手側から「リポジトリのReadアクセスを一時的に付与します」という対応をいただき、ソースコードDDに入った際のケースです。git log -S "sk_live_" を走らせると、2年前のコミットにStripeのシークレットキーが含まれていることが判明しました。
そのキーに対してStripe APIで認証確認を実行すると、正常なレスポンスが返ってきました。つまり2年前に誰かが「削除した」と思っていたStripeのシークレットキーは、コミット履歴の中で2年間生き続け、かつDDの時点でまだ有効（ローテーションされていない）状態でした。この発見を売り手にフィードバックした際の反応は「え、削除したはずなのに」でした。削除したのはコードベースから。Gitの歴史からは削除されていない。その違いを、売り手も仲介業者も認識していませんでした。
4-2. 【ケース2】本番DBの接続文字列がREADMEにべた書きされていた7年越しの爆弾
別のSaaS事業のDD時に、README.md のコミット履歴を確認したところ、7年前の初期コミットに本番RDSの接続文字列（エンドポイント・ポート番号・ユーザー名・パスワード）が「環境構築手順」として記載されていることを発見しました。その後READMEの内容は何度も書き直され、現在のREADMEにはその情報は含まれていませんでした。
しかし git show [初期コミットのハッシュ]:README.md を実行すれば、7年前のべた書き情報が一瞬で復元されます。問題はそのパスワードが7年間ローテーションされていなかった点です。確認すると、現在もそのパスワードが本番RDSで使用されていました。このケースでは、値下げ交渉の材料として活用しつつ、クロージング前にパスワードのローテーションを条件として合意した上で譲渡を進めました。
4-3. 【ケース3】「テスト用」と称して会員3万人分のCSVがコミットされていた事実
3つ目のケースはより深刻です。テストデータ管理用のディレクトリの中に、users_backup_20220315.csv というファイルが含まれており、コミット履歴に実在する会員3万人分の氏名・メールアドレス・生年月日が記録されていました。売り手側の説明は「テスト用のデータです」でしたが、CSVの中身には明らかに実在するメールアドレスパターン（gmail.com・yahoo.co.jp等）が並んでおり、乱数生成のテストデータとは明らかに異なるものでした。後の確認で、本番DBから抽出したデータをそのままテスト用として流用していたことが判明しました。
このリポジトリは当時から現在まで一貫してプライベートリポジトリでしたが、「プライベートリポジトリだから安全」は過信です。GitHubアカウントの侵害・不正なDeployキーの漏洩・退職した元コントリビューターのアクセス権残存など、プライベートリポジトリへの不正アクセスリスクは多数存在します。このCSVの存在を根拠として、個人情報保護法上のリスクを定量化した上で買い手側の法務チームを入れての再交渉に持ち込みました。
5. GitGuardianとgit log ── 現役エンジニアが30分で剥がす秘密情報発掘ツールチェーン
5-1. git log -S・git show・git log --all-full-history ── CLI3コマンドで秘密情報を炙り出す実手順
追加費用ゼロで即座に実行できるCLIコマンドを整理します。まず全ブランチを対象にした秘密情報の検索：
git log -S "AKIA" --all --oneline
git log -S "sk_live" --all --oneline
git log -S "password" --all --oneline
git log -S "private_key" --all --oneline
git log -S "BEGIN RSA" --all --oneline疑わしいコミットのハッシュが判明したら、差分を確認します：
git show [ハッシュ] | grep -A 5 -B 5 "AKIA"削除されたファイルの履歴を追う場合は：
git log --all --full-history -- "**/*.env"
git log --all --full-history -- "**/*.pem"
git log --all --full-history -- "**/*.csv"これらのコマンドを一通り実行するだけで、主要な秘密情報の有無は30分以内に把握できます。
5-2. GitGuardian Historical Scan ── 全コミット履歴を自動スキャンして秘密情報を一覧化
git log -S はキーワードを事前に知っている必要があります。しかし未知のパターンの秘密情報を網羅的に発掘するには、自動検知ツールが有効です。GitGuardianはGitHubと連携してコミット履歴全体をスキャンし、350種類以上のシークレットパターン（AWS・GCP・Azure・Stripe・Slack・SendGrid・Twilio等）を自動検知します。無料プランでも個人・小規模チームのリポジトリに対してHistorical Scanが実行でき、全コミット履歴に対して漏洩した秘密情報の一覧をレポートとして出力します。
SaaSの買収交渉でリポジトリアクセスを得た直後にGitGuardianのHistorical Scanを走らせると、5〜10分で対象リポジトリの秘密情報漏洩状況を一覧化できます。このレポートをそのまま売り手へのフィードバックシートとして使えます。
5-3. truffleHog・gitleaks ── OSSベースで使える秘密情報検出スタックの比較と選定
GitGuardianへのアカウント連携が難しい場合、OSSベースの代替ツールとして以下が有効です。gitleaks（Go製）は gitleaks detect --source=. --log-opts="--all" 1コマンドで全ブランチ・全コミット履歴を横断スキャンし、検知した秘密情報をJSON/CSV形式でレポート出力します。インストールは brew install gitleaks で完了し、DDの現場で最も手軽に使えるツールです。
truffleHog（Python製）はエントロピー分析（文字の乱雑さ）を組み合わせることで、既知のパターン以外の「それっぽい文字列」も検出する強みがあります。AWS・GCPキーのように規則的なパターンを持つ秘密情報以外も拾えるため、カスタムの内製APIキーが使われている環境で特に有効です。gitleaksで既知パターンを網羅し、truffleHogでエントロピー異常を拾う2段構えが、DDにおける最も網羅性の高いスタックです。
6. BFGもfilter-branchもgit rebaseも「完全消去」にはならない理由
6-1. Gitのオブジェクトストアとreflogの構造 ── 「削除」が論理削除に過ぎない設計原理
「履歴からAWSキーを完全に消す」ために git filter-branch や BFG Repo Cleaner を使う方法は広く知られています。これらのツールは確かに、対象のコミットから指定したファイルや文字列を書き換えた「新しいコミット履歴」を生成します。しかし重要な点は、元のオブジェクト（書き換え前のコミットハッシュ）はGitのオブジェクトストアとreflogに残り続けるという事実です。
git filter-branch 実行後も、.git/refs/original/ 以下に書き換え前の参照が保存されます。git gc --prune=now と git reflog expire --expire=now --all を組み合わせることで元のオブジェクトを削除できますが、それはあくまでローカルリポジトリの話です。
6-2. GitHubのキャッシュ・fork・クローン済み環境が履歴を永続させるメカニズム
ローカルで完全に書き換えたとしても、GitHubにforce pushした後もGitHubのサーバーキャッシュには元の履歴が一定期間残ります。また、git clone 済みの開発者の手元には元の履歴が丸ごと残っています。forkされているリポジトリがあれば、そこにも元の汚染済み履歴が保存されています。
さらに、CI/CDシステム（GitHub Actions・CircleCI・Jenkins等）が持つキャッシュ、過去のPull RequestのコメントやコミットへのリンクURL、過去のDeploymentの記録にも「元のコミットハッシュ」が参照として残っています。Gitの書き換えは「なかったことにする」ではなく「なかったことにしようとしている痕跡が各所に残る」という状態に過ぎません。
6-3. 本当の対処法は「キーのローテーション」 ── 履歴を消すより、鍵を無効化することが先決
結論として、Gitの歴史から秘密情報を「完全に消す」ことは現実的には不可能です。では何をすべきか。答えは「履歴を消すより、漏洩した鍵を無効化する」です。AWSキーが漏洩していれば、IAMコンソールでそのアクセスキーを即時無効化し、新しいキーを発行する。Stripeキーが漏洩していれば、Stripeダッシュボードでそのシークレットキーをロールオーバーする。DBパスワードが漏洩していれば、RDSのマスターパスワードを変更し、アプリケーション側の接続情報を更新する。
「コミット履歴に秘密情報が残っている」という事実は変わりませんが、その秘密情報が無効化されていれば、攻撃者が入手しても何も実行できません。売り手側にDDの前に求めるべきは「履歴の書き換え」ではなく、「漏洩済みキーの全件ローテーション完了エビデンス」です。
7. 公開リポジトリと非公開リポジトリ ── DDの確認手順と見落としやすいパターン
7-1. 公開リポジトリはGitHub SearchとgitleaksでDD前から誰でも発掘可能という現実
対象事業のリポジトリがパブリックであった場合、その秘密情報は既に世界中から検索可能な状態にある可能性があります。GitHubの全文検索は org:対象組織名 sk_live_ のような検索でコミット内容まで検索でき、Webブラウザから誰でも実行できます。
さらに深刻なのは、GitHubの全コミット履歴を継続的にスキャンしているボットが複数存在し、漏洩したAPIキーを数分以内に発見して不正利用を開始するケースが実際に報告されていることです。AWSはこの問題に対応するため、GitHubと連携してAWSキーパターンを含むコミットを自動検知し、IAMでアクセスを一時停止する機能を提供していますが、全ての秘密情報に対してこのような保護があるわけではありません。
7-2. 非公開リポジトリへのアクセス権交渉 ── NDA締結後の確認権限をLOI前に合意に盛り込む
買い手側がソースコードDDを実施するためには、売り手リポジトリへの一時的なReadアクセスが必要です。この権限付与のタイミングと条件を、LOI（基本合意書）に明示的に盛り込むことを強く推奨します。
「NDA締結後、LOI締結前の段階でリポジトリのReadアクセスを付与する」という合意が取れていれば、LOI前の早期段階でgitleaksを走らせてリスクの大枠を把握できます。LOI後にDD工程に入ってから初めてリポジトリアクセスを得るパターンでは、致命的なリスクを発見した時点でLOI後の値下げ交渉という難しい立場に立たされます。リポジトリアクセスのタイミング条件は、M&A交渉の初期段階で合意すべき技術的な必須事項です。
7-3. 「かつてpublicだったリポジトリ」をprivateに変えても、WebArchiveには残り続ける
「以前はパブリックだったが、今はプライベートに切り替えた」というリポジトリについては、Wayback Machine（web.archive.org）にGitHub上のファイル内容がキャッシュされている可能性があります。また、GitHubはパブリックリポジトリのコンテンツを検索エンジンにインデックスさせており、プライベートに切り替えた後も、検索エンジンのキャッシュに秘密情報が残存する期間が存在します。
売り手が「公開リポジトリをプライベートに変えたから問題ない」と認識している場合、それは過信である可能性を買い手側は念頭に置くべきです。パブリックであった期間・コントリビューター数・外部へのfork状況を確認し、WebArchiveでの残存を合わせて確認することが、DDにおける正しい手順です。
8. 売り手が「クリーンな履歴」で価格を守るための逆説的アプローチ
8-1. 譲渡前に自主でgitleaksを走らせ、発見した秘密情報を先に開示する
売り手としての立場から申し上げます。gitleaks detect --source=. --log-opts="--all" は、インストールから実行まで10分でできる作業です。譲渡を検討し始めた時点で、このスキャンを自主的に実行してください。
何も検出されなければ、その事実をIMに一行添えることができます。「本リポジトリに対してgitleaksによる秘密情報スキャンを実施済み。検出事項なし。」これだけで、技術系の買い手への心象は大きく変わります。検出されたとしても、それは隠蔽すべき情報ではなく先手で開示すべき情報です。「スキャンを実施したところ、2年前のコミットにStripeキーが検出されました。現在当該キーはローテーション済みです。以下にエビデンスを添付します。」このように自主開示と是正完了をセットで提示した売り手が、DDの過程で発見された買い手より大幅に有利な交渉立場に立てることは明白です。
8-2. キーのローテーション完了エビデンスをIMに同封した売り手が、最も信頼される
具体的なエビデンスとして提示できるものを列挙します。AWSであればIAMコンソールのアクセスキー一覧（作成日が最近のもの）のスクリーンショット、Stripeであればダッシュボードのシークレットキー欄のスクリーンショット（ローテーション後のキーの先頭数文字と作成日）、RDSであればパスワード変更のAuditログ。これらを「技術的DDチェックリスト（是正完了版）」としてまとめてIMに同封することは、買い手側のソースコードDD工数を大幅に削減し、クロージングまでのスピードアップに直結します。
DDが速く終われば早期譲渡が実現し、売り手のキャッシュ受け取りタイミングも早まります。技術的に誠実な売り手の姿勢は、それ自体が譲渡価格を守る盾として機能します。
8-3. 自主開示と隠蔽の分岐点 ── 表明保証違反として追われる前に先手を打つ
「知らなかった」は通用しません。ソースコードに秘密情報が残っている事実を売り手が認識していたにもかかわらず、IMや表明保証書にその記載をしなかった場合、買収後に発覚した際の表明保証違反リスクは極めて高くなります。M&A契約書の表明保証条項には「対象事業に関連するソフトウェアにおいて、第三者の権利を侵害し、または重大なセキュリティ上の瑕疵を有する事実は存在しない」旨が盛り込まれることが通例です。Gitのコミット履歴に未ローテーションの本番APIキーが残存している事実は、この表明に抵触する可能性があります。
隠蔽して後から発覚するより、自主開示して是正完了のエビデンスと共に開示する方が、最終的な手取り額は確実に大きくなる。前回のOSSライセンス編でも触れた逆説が、ここでも成立します。
9. コードを読める買い手だけが、Gitの地雷を踏まずに済む
ここまで、なぜGitのコミット履歴がM&Aの核になるのか、何が埋まっているのか、なぜ削除しても消えないのか、どのツールで発掘するのか、そして売り手と買い手それぞれが取るべき具体的なアクションを整理してきました。
これらに共通するのは「コードを書いたことがある人間でなければ、そもそもこの論点の存在すら認知できない」という事実です。財務系のDDは数字を精査し、弁護士は契約書を読み、税理士は税務処理を確認する。誰の標準工程にも、git log -S "AKIA" を走らせてコミット履歴を掘る作業は入っていません。
買い手としては、リポジトリへのReadアクセスをNDA締結と同時に確保することをLOIに盛り込み、gitleaksによる全履歴スキャンをDDの初日に実施すること。売り手としては、譲渡準備の開始時点で自主スキャンを実施し、発見した秘密情報を全て先行ローテーションしてそのエビデンスをIMに添付すること。どちらの立場でもこの工程を「余計な手間」ではなく「最後の防衛ライン」として位置づけることが、コミット履歴という見えない地雷を踏まずに済む唯一の方法です。IMの数字だけを見て動く買い手と、コードを読める買い手では、同じ譲渡案件から全く異なるリスクプロファイルが見えています。この差が、M&Aの最終局面で明暗を分けます。
