Gitleaks 機密情報漏洩対策完全ガイド｜Gitリポジトリの機密情報を守る3層防御

gitleaks-git-secret-leak-prevention DevOps
つのまる
つのまる

本記事ではGitleaksで漏洩を検知する方法から、万が一起きてしまった時の復旧手順まで、私が実際に手元で試した結果を交えて解説します。Gitリポジトリの機密情報を守る3層防御モデルもあわせて紹介します。

Gitリポジトリの機密情報漏洩はなぜ起きるのか

まずは、なぜ漏洩が起きるのかを整理しておきます。

漏洩の典型的な経路は、ざっと次のとおりです。

  • .gitignoreの書き忘れ・誤字
  • ローカルで動かすために一時的に直書きした認証情報の消し忘れ
  • 設定ファイルテンプレートに本物の値を残したままコミット
  • パブリック化（公開・フォーク）の際にコミット履歴ごと公開してしまう

つまり、人間が「うっかり」やってしまう以上、ゼロにはできません。だからこそ、機械的に検知する仕組みが必要になります。

漏洩リスクを下げる3層の対策モデル

次に、私が実務で組んでいる3層の防御モデルを紹介します。

層目的主な手段
第1層：予防そもそもリポジトリに書き込まない環境変数化、AWS Vault、direnv、.env.example運用
第2層：検知入ってしまった/入りそうなものを止めるGitleaksによるpre-commit + CIスキャン
第3層：復旧漏れたら被害を最小化する即時ローテーション、git履歴の削除、影響調査

第1層だけでは「うっかり」を完全には防げません。一方で、第3層しか持っていないと、漏洩の発見が遅れて被害が広がります。そのため、3層すべてを薄くでも持っておくのが現実的です。

本記事では、第2層の中心となるGitleaksを軸に解説します。

Gitleaks とは｜漏洩検知の定番ツール

率直にいうと、現在の機密情報スキャナの選定ではGitleaksが一番無難です。

GitleaksはGitリポジトリやファイルから、APIキー・トークン・パスワードといった機密情報をパターンマッチで検出するオープンソースツールです。Go製のシングルバイナリで動くため、ローカルでもCIでも導入しやすいのが特徴です。

ソースコードはgitleaks/gitleaks（MITライセンス）で公開されています。

検出できるシークレットは、たとえば次のような種類です。

  • AWS / GCP / Azureの各種キー
  • GitHub / GitLabトークン
  • Slack / Stripe / SendGridなどのSaaS APIキー
  • 秘密鍵（RSA、OpenSSH、PGP）
  • 任意の正規表現で追加可能

ここで大事なのは、Gitleaksは「100%検知できる魔法のツール」ではないという点です。Gitleaksの漏洩検知はパターンマッチなので、独自フォーマットの認証情報は素通りします。そのため、第1層・第3層と組み合わせる前提で使いましょう。

Gitleaks のインストールと基本コマンド

ここから具体的な使い方に入ります。

インストール

私はmacOSとWindowsの両方で使っているので、それぞれの導入手順を載せておきます。

macOS（Homebrew）の場合はこうです。

brew install gitleaks

Windows（Scoop）の場合はこちらです。

scoop install gitleaks

Docker派の方はこちらでもOKです。

docker pull ghcr.io/gitleaks/gitleaks:latest

インストール後、gitleaks versionでバージョンが表示されれば準備完了です。

過去コミット履歴をスキャン（gitleaks git）

実際に既存リポジトリの履歴をまるごとスキャンするには、次のコマンドを使います。

gitleaks git -v /path/to/repo

-vで詳細出力、出力先を変えるなら--report-path leaks.jsonを付けます。

私の手元のリポジトリ（コミット約3,000件）では、初回スキャンに約12秒かかりました。古めのMacBook Air（M2）でもストレスなく回せる速度です。

作業ツリーをスキャン（gitleaks dir）

git履歴ではなく、現在のファイルシステムだけを見たい場合はこちらです。

gitleaks dir -v /path/to/dir

node_modulesやビルド成果物を含めたくない場合は、設定ファイル（.gitleaks.toml）のallowlist.pathsに正規表現で除外パスを書きます。

pre-commit hookで「書き込んだ瞬間」に止める

検知の効きを最大化するには、コミット前に止めるのが理想です。

私はpre-commitフレームワーク経由でGitleaksをフックに登録しています。リポジトリのルートに.pre-commit-config.yamlを作ります。

repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.30.1
    hooks:
      - id: gitleaks

そのうえで、次のコマンドを一度だけ実行します。

pre-commit install

これでgit commitするたびにステージされた変更がスキャンされ、機密情報が含まれるとコミットがブロックされます。

緊急で回避したい時はSKIP=gitleaks git commit -m "..."でスキップできます。とはいえ、私の経験上、スキップすると忘れて漏洩しがちです。安易に使わないほうが無難です。

GitHub Actionsで「PRで」止める

ローカルだけだと、フックを入れていないメンバーをすり抜けてしまいます。そのため、私はCI側にも必ず仕込んでいます。

最小構成のワークフロー例です。

name: gitleaks
on: [pull_request, push]

jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - uses: gitleaks/gitleaks-action@v2
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

fetch-depth: 0を指定する理由は、過去コミットも含めて全件スキャンするためです。デフォルトの浅いcloneだと履歴を見逃します。

つまり、ローカルでpre-commit、リモートでGitHub Actions、という二段構えにしておくと、誰かのうっかりにも対応できます。私のチーム運用ではこの形に落ち着いています。

漏洩してしまった時の復旧3ステップ

ここからは、検知ではなく起きてしまった後の話です。

ステップ1：シークレットを即ローテーション

最優先は、漏洩した認証情報そのものを無効化することです。

git履歴から消すのは2番目です。なぜなら、消すまでの間にすでに第三者がクローンしている可能性があるからです。

  • AWSなら IAM > アクセスキー > 無効化 → 削除
  • GitHub PATなら Settings > Developer settings > Tokens > Revoke
  • DBパスワードなら即変更し、旧パスワードでの接続を遮断

私はAWS資格情報の日常的な管理にAWS Vaultを使っています。詳しい運用はAWS Vault + SSMでEC2のSSHを無効化で書きました。

ステップ2：git履歴から完全削除（git filter-repo）

ローテーションが済んだら、リポジトリ履歴からも消しておきます。

最近はgit filter-branchではなくgit-filter-repoが公式推奨です。

git filter-repo --path config/secrets.yml --invert-paths
git push origin --force --all

force pushが必須になるため、共同開発者には事前周知が必要です。私はSlackで一報入れてから実行するようにしています。

ステップ3：影響範囲を調査する

最後に、何にどこまで影響したかを確認します。

  • AWSなら CloudTrail で当該キーのAPI呼び出し履歴を確認
  • GitHubなら Audit log でトークンの利用先を確認
  • Webhook URLなら通知先のログを確認

「漏れた → 消した → 終わり」ではなく、第三者に使われていないかまで追うのが復旧の本筋です。

誤検知と除外設定のコツ

実運用していると、必ず誤検知に当たります。

たとえばテスト用のダミーAWSキーや、ドキュメント中のサンプルトークンを、Gitleaksが本物として検出してしまうケースです。これを毎回ブロックされると、開発者の心理的な負担が大きくなります。

主な除外手段は3つです。

  • ソース内コメント# gitleaks:allowを該当行末尾に付ける
  • .gitleaksignoreにfingerprintを書く（gitleaks git --report-pathで出るID）
  • .gitleaks.tomlのallowlistセクションでパスや正規表現を除外

私は基本的に.gitleaks.tomlのallowlistで管理しています。なぜなら、行コメント方式だとレビューで見落としやすいからです。集中管理のほうが、何を許可しているかをチームで把握しやすくなります。

まとめ｜漏洩対策はゼロ・ワンではなく層で考える

最後にもう一度、Gitleaksでの漏洩対策の要点を整理します。

  • 第1層：そもそも書き込まない（環境変数・Vault・テンプレ運用）
  • 第2層：Gitleaksでpre-commit + GitHub Actionsの二段検知
  • 第3層：漏れたら即ローテーション → 履歴削除 → 影響調査

完璧な予防はありません。Gitleaksは漏洩を防ぐ最後の砦というより、「うっかりを早期に拾うネット」として機能します。だからこそ、3層を薄くでも持っておくのが現実的です。

みなさんの今のリポジトリでも、まず一度gitleaks git -v .を流してみてください。過去の自分から思わぬプレゼントが出てくるかもしれません。出てきたら、本記事の復旧手順を参考にしながら、落ち着いて対処していきましょう！