gitleaks/gitleaks とは何ですか？

git リポジトリやファイル、stdin から秘密情報を検出する Go 製 CLI。README が「機能追加は行わない、今後はセキュリティパッチのみ」と明示しているため、採用判断は新機能ではなく現行ルールセットと保守方針の確認が中心になる。

gitleaks/gitleaks は商用利用できますか？

できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。

gitleaks/gitleaks は今もメンテナンスされていますか？

されています。最後のコミットは 7 日前です。

gitleaks/gitleaks はどのプログラミング言語で書かれていますか？

主に Go です（GitHub の言語統計による）。

Gitleaks レビュー: regex 検出の仕組み、導入コマンド、feature complete の制約

ひと目でわかる

これは何？: git リポジトリやファイル、stdin から秘密情報を検出する Go 製 CLI。README が「機能追加は行わない、今後はセキュリティパッチのみ」と明示しているため、採用判断は新機能ではなく現行ルールセットと保守方針の確認が中心になる。
誰に向いている？: すでに CI や pre-commit に gitleaks を組み込み、ルールセットが自組織の検出対象に合っているなら、v8.30.1 は MIT ライセンスのまま使い続けられる。逆に、新しい検出対象やアーカイブ・エンコード済みペイロードへの対応を期待して導入するのは筋が悪い。
商用利用できる？: できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
今もメンテナンスされている？: されています。最後のコミットは 7 日前です。
何の言語で書かれている？: 主に Go です（GitHub の言語統計による）。

回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。

オープンソース詳細解説

Hysen Labs 編集部 · 2026年9月10日 · gitleaks/gitleaks

Gitleaks が解こうとしている問題は「コミット済みの秘密情報」である

パスワードや API キー、トークンが git の履歴に残る問題は、ファイルを消しても履歴に残る点で厄介である。Gitleaks はこの検出に特化した CLI で、README は対象を「git repos, files, and whatever else you wanna throw at it via stdin」と説明している。つまり用途は、リポジトリの履歴走査、任意ディレクトリの走査、パイプ経由の単発チェックの3系統である。想定読者は、CI に秘密情報スキャンを入れたい開発者、pre-commit でコミット前に止めたいチーム、既存リポジトリの棚卸しをしたいセキュリティ担当者になる。検出はするが削除やローテーションはしない。出力される Finding を見て人間が鍵を無効化する、という役割分担が前提だ。

検出エンジンは regex とエントロピー、そして allowlist の組み合わせ

README は検出方式についてブログ「Regex is (almost) all you need」を参照させている。出力例から読み取れるのは、RuleID ごとに正規表現で候補を拾い、Entropy 値を併記する構造である。例では sidekiq-secret というルールが cafebabe:deadbeef を捕まえ、Entropy 2.609850 が付いている。つまり一致した文字列そのものではなく、ルール識別子とエントロピーという2つの手がかりで誤検知を絞る設計だ。Fingerprint はコミットハッシュ、ファイルパス、ルール ID、行番号を連結した形式で、同じ検出を後から特定するための安定した識別子として機能する。ルール定義はリポジトリ内の cmd/generate/config/rules/ 以下に Go ファイルとして置かれている点も出力例から確認できる。設定ファイルを直接書く以外に、生成側のソースを読んでルールの意図を確認できる構造になっている。

導入は brew、Docker、ソースビルドの3経路

macOS は brew install gitleaks。Docker は docker pull zricethezav/gitleaks:latest または ghcr.io/gitleaks/gitleaks:latest で取得し、docker run -v ${path_to_host_folder_to_scan}:/path zricethezav/gitleaks:latest [COMMAND] [OPTIONS] [SOURCE_PATH] の形でホスト側ディレクトリをマウントして走査する。ソースからは git clone の後 make build である。コマンドは git、dir、stdin の3つに分かれており、README の使用例は gitleaks git -v で履歴を走査する形になっている。設定の優先順位は明示されていて、--config/-c、環境変数 GITLEAKS_CONFIG、環境変数 GITLEAKS_CONFIG_TOML にファイル内容を直接渡す、走査対象パス配下の .gitleaks.toml、の順に解決される。4つすべて使わなければ既定設定が使われる。CI で設定を差し替えたい場合、GITLEAKS_CONFIG_TOML に内容をそのまま渡せる点は、設定ファイルをリポジトリに置きたくない場合の逃げ道になる。

pre-commit で止めるか、CI で検出するか

README は pre-commit フックとしての組み込み手順を示している。.pre-commit-config.yaml に repo: https://github.com/gitleaks/gitleaks、rev: v8.24.2、hooks に id: gitleaks を書き、pre-commit autoupdate の後 pre-commit install を実行する。以降はコミット時に Detect hardcoded secrets が走り、秘密情報を含むコミットは Failed になる。緊急時は SKIP=gitleaks git commit で回避でき、その場合は Skipped と表示される。この SKIP の存在は運用上の重要点で、回避手段が用意されている以上、フックだけでは統制にならない。CI 側では gitleaks-action が用意されている。ローカルで止めてもリモートに push 済みの履歴は残るため、pre-commit と CI のどちらか一方ではなく、両方を置く前提で設計されていると読める。

誤検知との戦いを支える baseline と ignore の仕組み

実運用で効くのは検出そのものより除外の設計である。--baseline-path は「path to baseline with issues that can be ignored」と説明され、既知の検出をベースラインとして登録し、新規の検出だけを問題として扱える。--gitleaks-ignore-path は .gitleaksignore ファイルまたはそれを含むフォルダを指定し、既定はカレントディレクトリである。ここには出力例にある Fingerprint 形式、すなわちコミットハッシュとパスとルール ID と行番号の組を書くことになる。コード内に gitleaks:allow コメントを書いて個別に除外する方式もあり、--ignore-gitleaks-allow を付けるとそのコメントを無視して再び検出対象に戻せる。つまり除外はファイル側とコード側の二重構造で、後者を一時的に無効化して全件を見直す、という運用が想定されている。

既定では無効になっている走査深度という制約

見落としやすいのが --max-decode-depth と --max-archive-depth で、どちらも既定値は 0、つまり何もしない。README のフラグ説明には前者が「no decoding is done」、後者が「no archive traversal is done」と明記されている。Base64 などでエンコードされた秘密情報や、zip や tar の中に置かれた設定ファイルは、既定設定では検出対象にならない。深さを増やすほど走査コストと誤検知が増えるため、既定を安全側に倒していると解釈できる。逆に言えば、エンコード済みの鍵が混ざる環境では既定のままでは不十分で、意図的にこの2つを上げる必要がある。--max-target-megabytes で大きいファイルを除外できる点も合わせると、走査範囲は明示的に設計するものだという立場が読み取れる。

feature complete 宣言と Betterleaks への移行

このプロジェクトを評価するうえで最も重い事実は README 冒頭の警告である。Gitleaks is feature complete. I'm not merging new features into Gitleaks. Future releases will be security patches only. と書かれ、作者は Betterleaks に焦点を移すと述べている。リリース履歴もこれと整合する。v8.30.1 が 2026-03-21、v8.30.0 が 2025-11-26、v8.29.1 が 2025-11-19 で、v8.30.0 から v8.30.1 までに約4か月空いている。新機能の追加を期待して採用するのは方針に反する。一方でライセンスは MIT で、アーカイブされたリポジトリではないとされているため、既存の利用を続けること自体は妨げられない。判断の軸は「今後このツールが良くなるか」ではなく「現行のルールセットとバグ修正で当面足りるか」に置き換わる。

代替として何を比べるか、そして採用前に確認すべきこと

README が名指しする代替は Betterleaks である。同じ作者が次の焦点として挙げている以上、比較対象として最も自然だが、提供された資料には Betterleaks の機能、設定形式、gitleaks の .gitleaks.toml や baseline との互換性についての記述は一切ない。したがって「移行すべき」とも「互換性がある」ともここでは言えない。確認は Betterleaks 側のリポジトリで直接行う必要がある。別系統の選択肢としては、検出を regex ではなく言語の AST 解析や型情報に寄せるツールもあるが、この資料には具体的な製品名も比較データもないため、ここで名前を挙げて優劣を論じることはできない。採用判断で先に確認すべきは3点。自組織の鍵形式が .gitleaks.toml の rules で覆われているか、CI の実行時間に対して --max-decode-depth と --max-archive-depth をどこまで上げられるか、そして gitleaks:allow コメントと .gitleaksignore が既存コードベースにどれだけ存在し、棚卸しが必要かである。

編集部の結論

すでに CI や pre-commit に gitleaks を組み込み、ルールセットが自組織の検出対象に合っているなら、v8.30.1 は MIT ライセンスのまま使い続けられる。逆に、新しい検出対象やアーカイブ・エンコード済みペイロードへの対応を期待して導入するのは筋が悪い。README は「Future releases will be security patches only」と明記し、作者は Betterleaks に軸足を移すと書いている。導入前に確認すべきは .gitleaks.toml の rules が自組織の秘匿情報の形式を覆っているか、--max-decode-depth と --max-archive-depth の既定値 0 で足りるか、そして Betterleaks 側の互換性とルール移行コストである。

公式情報源

コミュニティノート