AWS Builder Center

Git シークレット検出ツールを比較してみる(2026 年版)

Git リポジトリへのシークレット混入を防ぐツール git-secrets、gitleaks、Betterleaks を 2026 年時点の情報で比較。導入手順、検出精度、CI/CD 統合、メンテナンス状況の観点から選定の判断軸を整理しました。

みなさん、こんにちは。AWS CLI が好きな kazzpapa3 a.k.a. ICHINO Kazuaki です。
このところアクセスキーの話ばかり書いている気がしますが、今日は流出経路となることが多い Git リポジトリへのシークレット混入を防ぐツールについて、2026 年時点の選択肢を整理します。

そもそもどこから流出しているのか

緊急時の対応であることと本質的にはお客様の環境に依存性がある点で、事態の復旧を見届けられているわけではなく、発生した事象ごとに詳細な流出経路をお伺いできていない側面はあります。
いくつか流出経路はあると考えられますが GitHub に代表されるバージョン管理システムに対してパブリック公開してしまったというケースは一定数発生例があります。
今回は、こうした事故を防ぐためのクライアントサイドツールとして、本エントリでは以下の 3 つを取り上げます。
ツール開発元言語ライセンス
git-secrets AWS LabsBashApache-2.0
gitleaks Gitleaks (OSS)GoMIT
Betterleaks Zach Rice、Aikido SecurityGoMIT
いずれも OSS であり、それぞれに特徴と向き不向きがあると考えられます。
そのため本エントリでは特定のツールを推奨するのではなく、あくまで判断材料としてフラットに提示するスタンスとします。
OSS 製品という性質を考慮し、機能の多寡に加えてメンテナンスの継続性など総合的にリスク評価いただき、採用可否をご判断いただけると幸いです。

各ツールの概要

git-secrets 

AWS Labs が提供する Bash 製のツールです。
Git フック(pre-commit、commit-msg、prepare-commit-msg)を利用してコミット時にシークレットをブロックします。

特徴

  • brew install git-secrets で即導入、設定もシンプル
  • --register-aws で AWS Access Key ID、Secret Access Key、Account ID のパターンを一括登録
  • Secret Provider 機能で外部コマンドの出力を動的に禁止パターンとして取り込み可能
  • AWS 以外のパターンは正規表現を用いて自分で追加する必要がある

現状(2026 年 5 月末時点)

  • リポジトリの更新頻度は低下しており、Issue が 93 件あり、Pull Request も 38 件がオープンのままとなっている
  • 機能追加は期待しにくいが、既存機能は安定して動作する
  • AWS パターンに特化しているため、AWS のみを利用する環境ではシンプルさが利点

gitleaks 

Go 製のシークレットスキャナーで、150 以上のビルトインルールを備えています。
CI/CD 統合に強く、GitHub Actions への公式対応や SARIF(Static Analysis Results Interchange Format) 出力をサポートしています。

特徴

  • AWS に限らず、Google Cloud、GitHub PAT、Slack、OpenAI など主要サービスのパターンを追加設定なしで検出可能
  • .gitleaks.toml でルールをコードとして管理でき、チームで共有も容易に行える
  • JSON、CSV、SARIF に対応し、カスタムテンプレートでの出力も可能
  • --baseline-path で既知の検出結果を除外し、差分のみ報告可能
  • pre-commit フレームワーク経由での導入に対応

現状(2026 年 5 月末時点)

  • README  に "Gitleaks is feature complete. Future releases will be security patches only." と明記されています [2]
  • この宣言で、作者の Zach Rice は後継の Betterleaks に注力を移し gitleaks への新機能追加は行わないと明言している
  • ただし、合わせてセキュリティパッチは提供するとも明言しているため、既存ユーザーが即座に移行を迫られる状況ではないと考えられる
  • 実質的な「放置」状態に近い git-secrets とは異なり、「意図的な完成宣言」である点で git-secrets とは異なる状況
  • Issue が 249 件、Pull Request も 156 件がオープンのままとなっている

Betterleaks 

まったくのノーマークだったのですが、今回調査を始めた際に前述の gitleaks の README での言及があったことで知ったソリューションです。
gitleaks の作者 Zach Rice が Aikido Security の Head of Secrets Scanning として開発した次世代ツールとのことです。
2026 年 3 月にローンチされたばかりで gitleaks の drop-in replacement(完全互換品)として設計されています。

特徴

リポジトリでの説明に加え Aikido Blog  でも詳細に説明されており、要約すると以下のような特徴を持っています。
  • gitleaks の CLI フラグ・設定ファイルをそのまま引き継げる
  • CEL(Common Expression Language)[3] ベースのバリデーションで、検出ルールにプログラマブルなフィルタリングを定義可能
  • Token Efficiency(BPE トークン化)による誤検知削減 — CredData データセットで 98.6% recall(entropy ベースは 70.4%)
  • エンコード済みシークレット(二重・三重エンコード)への対応
  • Pure Go 実装(CGO、Hyperscan 不要)で環境を選ばない

現状(2026 年 5 月末時点)

  • 2026-05-22 時点で v1.3.1 となり 200 コミット
  • v2 のロードマップとして LLM 分類、自動失効(プロバイダ API 経由)、パーミッションマッピング
  • 新しいプロジェクトであり、長期的な安定性は今後の実績次第
    • Aikido はこのプロジェクトを支援しているが、Aikido に依存しているわけではない、と言及している

比較表

観点git-secretsgitleaksBetterleaks
導入の手軽さ◎ brew + 2 コマンド○ brew + pre-commit 設定○ brew install betterleaks
ビルトインルールAWS のみ150 以上gitleaks 互換 + Token Efficiency
カスタムルール正規表現(gitconfig)正規表現(.gitleaks.toml)正規表現 + CEL フィルタ
誤検知管理.gitallowed.gitleaksignore + baseline.betterleaksignore + CEL
Secret Provider○(外部コマンド動的取り込み)××
CI/CD 統合自前スクリプトGitHub Actions 公式、SARIFGitHub Actions 対応、SARIF
スキャン対象Git リポジトリGit、ディレクトリGit、ディレクトリ、S3、GitHub
エンコード済み検出××○(自動)
スキャン速度大規模で遅いマルチスレッドで高速並列 Git スキャン + ahocorasick
メンテナンス状況低頻度セキュリティパッチのみ活発(月次リリース)
ライセンスApache-2.0MITMIT

導入手順(macOS)

git-secrets

1
2
3
4
brew install git-secrets
cd /path/to/my/repo
git secrets --install
git secrets --register-aws

gitleaks

1
2
3
4
5
brew install gitleaks

# スキャン実行
gitleaks detect # 全履歴スキャン
gitleaks protect --staged # ステージング済みファイルのスキャン

Betterleaks

1
2
3
4
5
brew install betterleaks

# スキャン実行
betterleaks git /path/to/repo
betterleaks dir /path/to/directory

選定の判断軸

前述の比較表にもある通り特徴が異なるため、技術選定はプロジェクトの状況に依存すると考えられます。
以下はやや主観ですが、判断軸の一例としてご参照ください。

AWS アクセスキーだけを手軽にブロックしたい場合

git-secrets が最もシンプルです。brew install → --install → --register-aws の 3 ステップで完了し、追加の設定ファイルも不要です。
また Secret Provider で IAM のアクセスキー一覧を動的に取り込む機能は他のツールにはないユニークな利点だと考えられます。

マルチサービス対応や CI/CD 統合が必要な場合

gitleaks は十分に成熟したツールといえ、150 以上のルールと GitHub Actions 公式対応を備えています。
ほんの 2 週間前ですが feature complete 宣言はされたものの、セキュリティパッチは継続されるため、既に導入済みの環境では今しばらくは安定した選択肢でありうる考えられます。

最新の検出技術・将来性を重視する場合

Betterleaks は gitleaks の後継として活発に開発されており、Token Efficiency や CEL バリデーションなど新しいアプローチを採用しています。
gitleaks からの移行コストが低い(drop-in replacement)とされている点も移行コストが抑えられると考えられます。
ただし、2026 年 3 月に公開された新しいプロジェクトであり、長期的な安定性は今後の実績で判断する必要がありそうです。

ツールに依らない多層防御の考え方

いずれのツールもクライアントサイドのフックとして動作するため、git commit --no-verify で回避可能です。
単一のツールに依存するのではなく、多層防御を構成することが重要です。
以下は考え方の例です。
1
2
3
ローカル(開発者 PC): git-secrets、gitleaks、Betterleaks — 即座にフィードバック
CI/CD(サーバー側): gitleaks or Betterleaks — 回避不可能、Pull Request マージ前にブロック
GitHub: Secret scanning(Push protection)— プラットフォームレベルの検出
  • Branch protection rules [4] で main ブランチへの直接プッシュを禁止し、Pull Request 経由を強制する
  • CI でのスキャンを必須ステータスチェックに設定し、検出時はマージをブロックする
上記のように、クライアント側は「うっかりコミットの即時フィードバック」としての位置付けにとどめ、CI は「回避を許さない最後の砦」として考えます。

シークレットが履歴に混入していた場合の対応

今回紹介したいずれかのツールでのスキャンで過去コミットにシークレットを発見した場合、以下の順序での対応が必要です。
  1. 即座にキーをローテーション
    • 履歴の消去より先に、漏洩したキーを無効化することが最優先
  2. 履歴からの削除
    • BFG Repo Cleaner [5] または git filter-repo [6] で該当コミットを書き換える
  3. チームへの周知
    • 履歴が書き換わるため、全員が git pull --rebase を実施するか、クローンし直す必要がある

まとめ

ここまで見てきたように 2026 年時点で Git におけるシークレット検出ツールは世代交代の過渡期にあると見られます。
  • git-secrets  は AWS 特化のシンプルさが強み。新機能は期待できないが、既存機能は安定
  • gitleaks  は feature complete 宣言済みだが、成熟したエコシステムと豊富なルールセットを持つ
  • Betterleaks  は gitleaks 作者による後継で、新しい検出技術と活発な開発が特徴
各ツールの特徴を再掲すると上記と言えるかと考えられますが、いずれも OSS 製品であり、プロジェクトの継続性は保証されません。
そのため重要なのは特定のツールへの依存ではなく、多層防御の構成と、シークレットが検出された際の対応フロー(ローテーション → 履歴削除 → 周知)を整備しておくことが肝要だと考えます。
本エントリがどなたかのご参考になれば幸いです。
ではまた。
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article