2026年5月1日に発生したマネーフォワードのGitHub不正アクセス事件は、エンジニアにとって「認証情報の漏洩は防ぎきれない」という前提に立った設計の重要性を突きつける深刻な教訓となりました。
本記事では、なぜGitHubの認証情報が漏洩し、なぜソースコード内に本番カード情報や認証キーが混入していたのかを技術的視点で分析し、同様の事態を防ぐための具体的な対策を提案します。
概要と技術的背景
今回の事案は、マネーフォワードが利用していた GitHub の認証情報が第三者に渡り、リポジトリがコピーされたことに端を発します。流出したデータには、ソースコードだけでなく、以下の機密情報が含まれていました。
- 個人情報：「マネーフォワード ビジネスカード」保持者370件の「氏名（アルファベット）」と「カード番号下4桁」。
- 認証情報：ソースコード内にハードコードされていた各種APIの認証キー・パスワード。
技術的な問題の本質は、リポジリが盗まれたこと自体よりも、「リポジトリの中に盗まれてはいけない情報が入っていた」点にあります。具体的には、テストや調査のために本番データを仮名化せずに混入させていたこと、そして環境変数等で分離すべきシークレットがソースコード内に存在していたことが致命傷となりました。
デザイナーGitHubの認証情報漏洩、本当に恐ろしいですね。リポジトリに機密情報が入っていたことが根本的な問題だったと…。
エンジニアはい、認証情報自体は狙われやすい。だからこそ、最悪漏洩しても被害を最小限に抑える設計が重要なんです。この事件は、それを改めて考えさせるきっかけになりました。
詳細解説
1. 認証情報漏洩の経路（防げない前提のセキュリティ）
GitHubの認証情報は、どれほど対策しても以下の経路で漏洩するリスクがあります。
- Stealer系マルウェア：開発者のPCからセッションCookieやSSH秘密鍵、PAT（Personal Access Token）を直接抜き取る。
- サードパーティ連携の侵害：CircleCI等の連携サービスが攻撃を受け、トークンが連鎖的に流出する。
- 巧妙なフィッシング：2FA（二要素認証）を有効にしていても、フィッシングプロキシによって突破される事例が増加しています。
2. 本番データのテスト流用と仮名化
今回、カード情報が混入した原因として、CI/E2Eテストのフィクスチャや、バグ調査時のダンプデータがgit addされた可能性が考えられます。本番データを開発環境で利用する際は、FakerやMimesisを用いた合成データへの置換、またはPostgreSQL Anonymizer等を用いた不可逆なマスキングが必須です。
3. Git履歴という落とし穴
Gitは変更履歴をすべて保持するため、最新のHEADでファイルを削除しても、過去のコミット履歴にシークレットが残っていれば攻撃者は容易に復元可能です。git-filter-repo や BFG Repo-Cleaner を用いた物理的な履歴削除が必要になります。
エンジニアマルウェアやフィッシングでPATが盗まれるのは日常茶飯事です。だから、コードの中に本番シークレットを入れるのは、金庫の鍵を金庫の外に貼り付けておくようなものなんですよ。
デザイナーなるほど、テストデータに本番情報を混入させない、Git履歴も完全に消す、というのは地味だけどすごく大事な対策なんですね。
クイック対談
エンジニア認証情報の漏洩をゼロにするのは不可能です。FIDO2/Passkeyベースの認証でない限り、セッションは盗まれます。だからこそ、コード側に鍵を置かない「疎結合」な設計が最後の砦になります。
デザイナーカード下4桁と氏名のセットは、PCI DSS上は許容されても、フィッシング詐欺の精緻なターゲットリストとして悪用されるため、リポジトリへの混入は絶対に避けるべきでした。
実装・利用例
シークレットの混入を「仕組み」で防ぐための具体的なツールとコマンドを紹介します。
gitleaksによるコミット前の自動検査
gitleaks は高速なスキャンが可能で、pre-commitフックに組み込むのに適しています。
# ローカルの変更分をコミット前にスキャン（pre-commitに推奨）
gitleaks protect --staged --verbose
# リポジトリの過去履歴をすべてスキャン
gitleaks detect --source . --log-opts="--all"TruffleHogによる有効な鍵の検知
TruffleHog は、検出されたシークレットが現在も有効（Verified）かどうかを実際に検証する機能を持っています。
# Git履歴全体をスキャンし、有効な鍵のみを特定する
trufflehog git file://. --only-verifiedシークレット管理サービスへの移行
ハードコードを撲滅するため、以下のいずれかのサービスを利用し、コードからは環境変数経由で参照するように構成します。
- AWS Secrets Manager / SSM Parameter Store
- GCP Secret Manager
- HashiCorp Vault
- Doppler / Infisical（シークレット管理に特化したSaaS）
デザイナーgitleaksやTruffleHogでコードをスキャンするのは必須ですね。でも、検出された後のシークレットの管理も重要だと感じました。
エンジニアまさにその通りです。だからAWS Secrets Managerのような専門サービスを使うべきなんです。コードとシークレットを分離することで、漏洩リスクを大幅に減らせますから。
まとめ
- 脱PATとOIDCの推進：長期的なPAT（Personal Access Token）を廃止し、GitHub Appの短期トークンや、OIDC経由でのID連携（Workload Identity）に切り替え、盗まれる「固定の鍵」をなくす。
- プッシュプロテクションの有効化：GitHub Advanced Securityの「Push Protection」を有効にし、シークレットを含むコミットをサーバー側で拒絶する。
- 仮名化の自動化：本番DBから開発環境へデータをコピーする経路にマスキング層を強制的に挟む仕組みを構築する。
- 初動対応の迅速化：マネーフォワードの事例のように、漏洩疑い時には「即時の鍵無効化」と「影響範囲の遮断（サービス一時停止）」を躊躇なく行える体制を整えておく。
GitHubリポジトリがコピーされても、そこに「死に金」ならぬ「死に鍵」と「ダミーデータ」しか入っていなければ、それはインシデントではなく、単なる「ソースコードの流出」で済みます。今すぐ自社リポジトリに対して gitleaks を実行し、過去の負債を棚卸してください。
エンジニア最終的に目指すのは『死に鍵』と『ダミーデータ』だけがリポジトリに入っている状態です。これでセキュリティインシデントではなく、ただのコード流出で済みます。
デザイナーGitHubがコピーされても安心できるなんて、最高の状態ですね！今すぐgitleaksを試してみます。
