Git のシークレット漏洩は、「そもそもリポジトリに入れない仕組み」「コミットの直前で止める仕組み」「漏れたときにすぐ無効化する手順」の3段構えで防ぎます。この記事では、WordPress の wp-config.php や .env を例に、.gitignore の正しい使い方、gitleaks によるコミット前チェック、GitHub のプッシュ保護、そして誤ってコミット・プッシュしてしまったときの対処の順番までを説明します。
何が漏れやすいのか
Git に入り込みやすい秘密情報には、次のようなものがあります。
- WordPress の
wp-config.php（DB のパスワード、認証用キーとソルト） .envファイル（API キー、SMTP のパスワード、決済サービスのキー）- SSH の秘密鍵、クラウドの認証情報ファイル
- DB のダンプファイル（ユーザーのメールアドレスやパスワードハッシュを含む）
- デバッグ用に一時的に書き込んだトークン
注意したいのは、Git は履歴をすべて保存する仕組みだという点です。あとのコミットでファイルを削除しても、過去のコミットには残り続けます。公開リポジトリに一度でもプッシュされた秘密情報は、自動で収集するボットにすぐ見つかる前提で考えるべきです。
第1段階：リポジトリに入れない
.gitignore は最初のコミットより前に書く
.gitignore は「まだ追跡していないファイル」を無視する仕組みです。すでにコミットしたファイルを後から .gitignore に書いても、追跡は続きます。新しいリポジトリでは、最初のコミットより前に .gitignore を用意します。
# 秘密情報を含む設定
wp-config.php
.env
.env.*
!.env.example
# 鍵・認証情報
*.pem
*.key
id_rsa*
id_ed25519*
# DB ダンプ・バックアップ
*.sql
*.sql.gz
wp-content/uploads/
wp-content/backups/!.env.example は「この1つだけは除外しない」という指定です。値をダミーにした見本ファイルをリポジトリに入れておくと、他の開発者がどの変数を用意すればよいか分かります。WordPress なら、本物の wp-config.php は除外し、値を環境変数から読む作りにするか、wp-config-sample.php を見本として扱います。
意図どおりに無視されているかは、次のコマンドで確認できます。
git check-ignore -v .env wp-config.php
git status --ignoredすでに追跡しているファイルを外す
過去にコミットしてしまったファイルは、.gitignore に書いたうえで追跡だけを外します。
git rm --cached wp-config.php
git commit -m "wp-config.php を追跡対象から外す"--cached を付けると、手元のファイルは残したまま Git の管理から外れます。ただし、これで消えるのは「今後のコミット」からだけで、過去の履歴には残っています。そのファイルに本物の秘密情報が入っていたなら、後述する「漏洩後の対処」が必要です。過去に入ったことがあるかは git log --all --oneline -- wp-config.php で確認できます。
PC 全体で除外するグローバル設定
エディターの作業ファイルや OS が作るファイルは、リポジトリごとではなく PC 全体の設定で除外しておくと、新しいリポジトリでも漏れません。
git config --global core.excludesFile ~/.gitignore_global第2段階：コミットの直前で止める
.gitignore は「ファイル名」でしか防げません。設定ファイルに直接書き込んだキーや、テスト用スクリプトに貼ったトークンは素通りします。そこで、コミットの内容そのものを検査する仕組みを入れます。
gitleaks を pre-commit で動かす
gitleaks は、よく使われる API キーやトークンの形式をパターンで検出するオープンソースのツールです。pre-commit フレームワークと組み合わせると、コミットのたびに自動で検査されます。
# .pre-commit-config.yaml
repos:
- repo: https://github.com/gitleaks/gitleaks
rev: v8.18.0 # 古い版の例。下の autoupdate で最新のタグに更新する
hooks:
- id: gitleakspip install pre-commit
pre-commit autoupdate # rev を最新のリリースに書き換える
pre-commit install # .git/hooks/pre-commit が作られる
pre-commit run --all-files # 既存のファイルを一度まとめて検査する導入時には、過去の履歴も一度検査しておきます。gitleaks はバージョン 8.19 前後でコマンド体系が変わり、新しい版では gitleaks git、古い版では gitleaks detect を使います（2026年10月現在）。手元の版で gitleaks --help を見て確認してください。
gitleaks git -v # 新しい版：リポジトリの履歴全体を検査検出されたものがダミー値や公開してよい値なら、.gitleaksignore に検出結果の識別子を書いて除外できます。ただし、除外は「本当に秘密ではない」と確かめたものに限ります。
pre-commit のフックは各開発者の PC に入れるもので、git commit --no-verify で飛ばすこともできます。チームで運用するなら、同じ検査を CI でも実行して、すり抜けを防ぐのが一般的です。
自分の目でも差分を見る
ツールはすべての形式を知っているわけではありません。社内システムのパスワードのように決まった形を持たない値は、パターン検出では見つからないことがあります。git add . でまとめて追加するより、git add -p で変更を1つずつ確認したり、コミット前に git diff --cached を眺めたりする習慣が、最後の防波堤になります。
第3段階：GitHub 側の保護を有効にする
GitHub には、プッシュされた内容から既知の形式のシークレットを検出する「シークレットスキャン」と、検出したプッシュをその場で拒否する「プッシュ保護」があります。公開リポジトリでは利用でき、非公開リポジトリでは有料プランの機能（GitHub Secret Protection など）が必要です。提供範囲や名称は変更されることがあるため、GitHub のドキュメントで現在の条件を確認してください。
プッシュ保護でブロックされたときに、理由を確かめずに「許可して続行」を選ぶのは避けます。ブロックされたコミットは手元で修正し、値を取り除いてからプッシュし直します。
漏洩してしまったときの対処の順番
誤ってプッシュしてしまった場合、真っ先にやるべきことは履歴の書き換えではなく、漏れた値を無効にすることです。
- キーを無効化して再発行する。 API キーは発行元の管理画面で失効させ、新しいものを作ります。DB パスワードは変更し、
wp-config.phpを更新します。WordPress の認証用キーとソルトを入れ替えると、ログイン中のユーザーはすべてログアウトされます。 - 不正利用がないか確認する。 クラウドの利用履歴、決済サービスの取引記録、メール送信サービスの送信ログなど、そのキーで何ができたかに応じて調べます。
- 履歴から取り除く。
git filter-repoなどのツールで、該当ファイルや文字列を過去のコミットから消します。
# 作業前にリポジトリ全体のバックアップ（ミラー）を取る
git clone --mirror git@github.com:example/site.git site-backup.git
# 新しく clone したリポジトリで実行する
git filter-repo --invert-paths --path wp-config.php
git push --force --all履歴の書き換えは、他の開発者の手元のリポジトリと食い違いを生むため、全員に clone し直してもらう必要があります。また、フォークや GitHub 上のキャッシュ、プルリクエストの参照などに古いコミットが残ることがあります。そのため、「履歴を消したから安全」とは考えず、手順1の無効化を済ませたうえでの後始末と位置づけてください。
まとめ
- Git は履歴をすべて残すため、一度コミットした秘密情報はファイルを消しても残ります。
- .gitignore は最初のコミット前に用意し、追跡済みのファイルは
git rm --cachedで外します。 - gitleaks を pre-commit と CI で動かし、ファイル名では防げない埋め込みのキーを検出します。
- GitHub のシークレットスキャンとプッシュ保護は、提供条件を確認して有効にします。
- 漏洩したら、まずキーの無効化と再発行、次に不正利用の確認、最後に履歴の書き換えの順で対処します。