みなさん、こんにちは。AWS CLI が好きなテクニカルサポート課の市野です。
このところアクセスキーの話ばかり書いている気がしますが、今日は流出経路となることが多い Git リポジトリへのシークレット混入を防ぐツールについて、2026 年時点の選択肢を整理します。
そもそもどこから流出しているのか
緊急時の対応であり、また本質的にはお客様の環境に依存性があります。そのため弊社としては事態の復旧作業や調査内容をすべて見届けられているわけではなく、発生した事象ごとに詳細な流出経路をお伺いできていない側面があります。
いくつか流出経路はあると考えられますが GitHub に代表されるバージョン管理システムに対してパブリック公開してしまったというケースは一定数発生例があります。
今回は、こうした事故を防ぐためのクライアントサイドツールとして、本エントリでは以下の 3 つを取り上げます。
| ツール | 開発元 | 言語 | ライセンス |
|---|---|---|---|
| git-secrets | AWS Labs | Bash | Apache-2.0 |
| gitleaks | Gitleaks (OSS) | Go | MIT |
| Betterleaks | Zach Rice、Aikido Security | Go | MIT |
いずれも 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、AWS 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)1 出力をサポートしています。
特徴
- 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-secrets | gitleaks | Betterleaks |
|---|---|---|---|
| 導入の手軽さ | ◎ 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 公式、SARIF | GitHub Actions 対応、SARIF |
| スキャン対象 | Git リポジトリ | Git、ディレクトリ | Git、ディレクトリ、S3、GitHub |
| エンコード済み検出 | × | × | ○(自動) |
| スキャン速度 | 大規模で遅い | マルチスレッドで高速 | 並列 Git スキャン + ahocorasick |
| メンテナンス状況 | 低頻度 | セキュリティパッチのみ | 活発(月次リリース) |
| ライセンス | Apache-2.0 | MIT | MIT |
導入手順(macOS)
git-secrets
brew install git-secrets cd /path/to/my/repo git secrets --install git secrets --register-aws
gitleaks
brew install gitleaks # スキャン実行 gitleaks detect # 全履歴スキャン gitleaks protect --staged # ステージング済みファイルのスキャン
Betterleaks
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 公式対応を備えています。
直近で feature complete 宣言はされたものの、セキュリティパッチは継続されるため、既に導入済みの環境では今しばらくは安定した選択肢でありうると考えられます。
最新の検出技術・将来性を重視する場合
Betterleaks は gitleaks の後継として活発に開発されており、Token Efficiency や CEL バリデーションなど新しいアプローチを採用しています。
gitleaks からの移行コストが低い(drop-in replacement)とされている点も利点と考えられます。
ただし、2026 年 3 月に公開された新しいプロジェクトであり、長期的な安定性は今後の実績で判断する必要がありそうです。
ツールに依らない多層防御の考え方
いずれのツールもクライアントサイドのフックとして動作するため、git commit --no-verify で回避可能です。
単一のツールに依存するのではなく、多層防御を構成することが重要です。
以下は考え方の例です。
ローカル(開発者 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 は「回避を許さない最後の砦」として考えます。
シークレットが履歴に混入していた場合の対応
今回紹介したいずれかのツールでのスキャンで過去コミットにシークレットを発見した場合、以下の順序での対応が必要です。
- 即座にキーをローテーション
- 履歴の消去より先に、漏洩したキーを無効化することが最優先
- 履歴からの削除
- チームへの周知
- 履歴が書き換わるため、全員が
git pull --rebaseを実施するか、クローンし直す必要がある
- 履歴が書き換わるため、全員が
まとめ
ここまで見てきたように 2026 年時点で Git におけるシークレット検出ツールは世代交代の過渡期にあると見られます。
- git-secrets は AWS 特化のシンプルさが強み。新機能は期待できないが、既存機能は安定
- gitleaks は feature complete 宣言済みだが、成熟したエコシステムと豊富なルールセットを持つ
- Betterleaks は gitleaks 作者による後継で、新しい検出技術と活発な開発が特徴
各ツールの特徴は上記の通りですが、いずれも OSS 製品であり、プロジェクトの継続性は保証されません。
そのため重要なのは特定のツールへの依存ではなく、多層防御の構成と、シークレットが検出された際の対応フロー(ローテーション → 履歴削除 → 周知)を整備しておくことが肝要です。
本エントリがどなたかのご参考になれば幸いです。
ではまた。
- https://docs.oasis-open.org/sarif/sarif/v2.1.0/sarif-v2.1.0.html↩
- なおこの宣言は 2026-05-21 のコミット 80093b8 でされたばかりのようです↩
- https://cel.dev/↩
- https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/managing-a-branch-protection-rule↩
- https://rtyley.github.io/bfg-repo-cleaner/↩
- https://github.com/newren/git-filter-repo↩
市野 和明 (記事一覧)
マネージドサービス部・テクニカルサポート課
お客様から寄せられたご質問や技術検証を通じて得られた気づきを投稿していきます。
情シスだった前職までの経験で、UI がコロコロ変わる AWS においては GUI で手順を残していると画面構成が変わってしまって後々まごつくことが多かった経験から、極力変わりにくい AWS CLI での記事が多めです。
X(Twitter):@kazzpapa3(AWS Community Builder)