--- title: "gitleaksとは？使い方・設定とBetterleaksへの移行判断【v8.30.1で実測】" url: "https://www.issoh.co.jp/tech/details/10403/" published: 2025-12-25 updated: 2026-11-03 categories: ["セキュリティ"] publisher: "株式会社一創" --- # gitleaksとは？使い方・設定とBetterleaksへの移行判断【v8.30.1で実測】 gitleaksは、ソースコードとGitのコミット履歴に紛れ込んだAPIキー・トークン・パスワードを探すコマンドラインツールです。MITライセンスで公開され、v8.30.1の既定設定には222個の検出ルールが入っています。2026年10月時点で押さえておくべき変化は3つあります。コマンド体系が`detect`から`git`・`dir`へ移ったこと、UbuntuのLTSでaptから入る版が8.16.0のまま止まっていること、そして作者が機能追加の終了を宣言し、後継のBetterleaksへ移ったことです。本記事では、v8.30.1とBetterleaks 1.9.0を同じ検証リポジトリで実行した結果をもとに、使い方と移行の判断までを解説します。 ## まとめ gitleaksは正規表現とエントロピー判定で秘密情報を探し、Gitの全コミット履歴まで遡れる点が、作業ツリーしか見ないLinterとの違いです。検証では、削除済みファイルのGitHubトークンが`gitleaks dir`では見つからず、`gitleaks git`では検出されました。最新版はv8.30.1（2026年3月21日公開）で、Homebrew・winget・Scoop・Dockerで入ります。UbuntuのLTSはaptの版が古いので、リリースのtar.gzを使います。 CIは終了コード（検出ありで1）で止め、誤検知は`.gitleaksignore`・`gitleaks:allow`・baselineで抑えます。公式のgitleaks-actionをGitHubホストランナーで使う場合は`gitleaks-action@v3`へ更新し、組織アカウントでは無料のライセンスキーも要ります。 **既にgitleaksを回している環境は、急いで乗り換える必要はありません。**新規導入なら後継のBetterleaksの安定版1.9.0を候補に加えます。1.9.0は既存の`.gitleaks.toml`と`.gitleaksignore`をそのまま読み、鍵が今も有効かをAPIで確かめられます。開発中のv2は設定の自動探索・`.gitleaksignore`・baseline・SARIFを廃止するので、互換を前提にした移行はv1系で行います。 ## gitleaksの検出方式とスキャン対象 ### 正規表現とエントロピーによる二段の絞り込み gitleaksは、ルールごとに定義したGo言語の正規表現で候補を拾い、必要に応じてシャノンエントロピーの閾値でランダム性の低い文字列を落とします。v8.30.1の既定設定（[config/gitleaks.toml](https://github.com/gitleaks/gitleaks/blob/v8.30.1/config/gitleaks.toml)）には222個のルールがあり、AWSのアクセスキー、GitHubの個人アクセストークン、AnthropicのAPIキーなど、サービス固有の書式を個別に持ちます。 検証用リポジトリに架空のGitHubトークンを入れて`--redact`付きで実行すると、1件ごとに次の情報が出ます。 ``` $ gitleaks git -v --redact repo Finding: export GITHUB_TOKEN=REDACTED Secret: REDACTED RuleID: github-pat Entropy: 4.903056 File: deploy.sh Line: 1 Commit: 9db1f2ad9f4539cd19f0e4a192be270a24fb7e34 Author: tester Email: t@example.com Date: 2026-10-16T12:05:13Z Fingerprint: 9db1f2ad9f4539cd19f0e4a192be270a24fb7e34:deploy.sh:github-pat:1 ``` 誰がいつ持ち込んだかはCommit・Author・Dateで追えます。Fingerprintは後述する除外設定のキーです。ログを人に見せる運用なら`--redact`を常に付けます。 ### git履歴・ディレクトリ・標準入力の3つのスキャン対象 スキャンの入口は3つです。`gitleaks git`は`git log -p`の差分を読んで全コミットを検査し、`gitleaks dir`は現在のファイルだけを、`gitleaks stdin`はパイプで渡したデータを検査します。範囲を絞りたいときは`--log-opts`でgit logのオプションをそのまま渡せます。 ``` # リポジトリの全履歴をスキャン gitleaks git -v path_to_repo # 直近のコミット範囲だけをスキャン gitleaks git -v --log-opts="--all commitA..commitB" path_to_repo # 作業ツリーのファイルだけをスキャン（履歴は見ない） gitleaks dir -v path_to_directory # 標準入力から cat some_file | gitleaks stdin -v ``` base64などでエンコードされた値は既定で5段まで復号して検査します（`--max-decode-depth`）。一方、zipやtar.gzの中身は`--max-archive-depth`の既定が0なので、**指定しない限り読みません**（アーカイブ走査はv8.27.0で追加）。 ## v8.30.1の検証リポジトリで確かめた検出の挙動 macOS（x86\_64）で公式リリースのv8.30.1をチェックサム照合して導入し、2コミットの検証リポジトリを作りました。1つ目のコミットでAWSのアクセスキーIDとシークレットを書いた`config.py`、GitHubトークンを書いた`deploy.sh`、`password = "changeme"`だけの`ok.py`を追加し、2つ目で`deploy.sh`を削除しています。鍵はすべて乱数で作った実在しない値です。 ### 削除済みトークンの検出：dirとgitの比較 | 実行コマンド | 検出数 | 検出したルール | 終了コード | | ---------------------------- | --- | ------------------------------------------- | ----- | | gitleaks git | 3件 | github-pat・aws-access-token・generic-api-key | 1 | | gitleaks dir | 2件 | aws-access-token・generic-api-key | 1 | | `gitleaks git --exit-code 0` | 3件 | 同上 | 0 | | 存在しないフラグを付けて実行 | なし | なし | 126 | `deploy.sh`は作業ツリーにありませんが、`gitleaks git`は追加時のコミット差分からトークンを見つけました。ファイルを消しても鍵は履歴に残ります。既存リポジトリへの初回導入は、`dir`ではなく`git`で全履歴を見てください。`password = "changeme"`はどちらでも検出されませんでした。 ### AWS公式サンプルキーの既定除外 AWSのドキュメントにある`AKIAIOSFODNN7EXAMPLE`を流し込むと、結果は「no leaks found」でした。既定のaws-access-tokenルールに、末尾が`EXAMPLE`の値を除外するallowlistがあるためです。動作確認で「検出されない」ときは、テスト値が除外パターンに当たっていないかを先に疑い、ルールの書式に合わせた乱数の値で試してください。 ### zip内部の検査とmax-archive-depthの指定 同じ`config.py`をzipに固めて`gitleaks dir`にかけると、走査量0バイトで検出なし、`--max-archive-depth 2`を付けると2件を検出しました。成果物やバックアップのアーカイブがリポジトリにあるなら、このフラグが要ります。 ``` gitleaks dir --max-archive-depth 2 path_to_directory ``` ## v8.19.0で変わったコマンド体系 ### detect・protectからgit・dirへの書き換え v8.19.0（2024年9月14日公開）で`detect`と`protect`は非推奨になりました。検証でも`gitleaks detect --source repo`は`git`と同じ3件を返しましたが、`--help`の一覧では、スキャン用コマンドとして`dir`・`git`・`stdin`が表示されます。「gitleaks detect」で見つかる手順の多くは2023年前後のものです。 | 旧コマンド（非推奨） | 現行コマンド | 対象 | | --------------------------------- | ------------------------------------ | ----------- | | gitleaks detect | gitleaks git | コミット履歴 | | `gitleaks detect --no-git` | gitleaks dir | ファイル・ディレクトリ | | `gitleaks detect --no-git --pipe` | gitleaks stdin | 標準入力 | | gitleaks protect | `gitleaks git --pre-commit` | 未コミットの差分 | | `gitleaks protect --staged` | `gitleaks git --pre-commit --staged` | ステージ済みの差分 | `--source`による対象指定は位置引数に変わり、省略するとカレントディレクトリが対象です。`protect`の後継が`gitleaks git --pre-commit`であることは、公式の[.pre-commit-hooks.yaml](https://github.com/gitleaks/gitleaks/blob/master/.pre-commit-hooks.yaml)が`gitleaks git --pre-commit --redact --staged --verbose`を呼んでいることからも確認できます。 ### 終了コードとCIでの成否判定 既定の終了コードは、検出なしで0、検出またはエラーで1、未知のフラグで126です。1が返った場合はログを確認し、秘密情報の検出と実行エラーを区別します。導入直後に「報告するがビルドは落とさない」期間を置くなら`--exit-code 0`を指定します。 ``` # 検出があってもジョブを失敗させない（導入初期の可視化フェーズ向け） gitleaks git -v --redact --exit-code 0 --report-format sarif --report-path gitleaks.sarif ``` レポート形式は`--report-format`でjson・csv・junit・sarif・templateから選べます。sarifを`github/codeql-action/upload-sarif`へ渡せば、検出結果がGitHubのCode Scanningタブに並びます。GitHubへの不正アクセスが事業サービスの停止にまで及んだ事例は、[マネーフォワードのGitHub不正アクセス事案の全容](/tech/details/11988/)で整理しています。 ## OS別のインストール手順 ### Windowsでのwinget・Scoop・zip導入 公式READMEはWindowsのパッケージマネージャーに触れていませんが、[wingetの公式リポジトリ](https://github.com/microsoft/winget-pkgs/tree/master/manifests/g/Gitleaks/Gitleaks)にパッケージID `Gitleaks.Gitleaks`として8.30.1が、Scoopのmainバケットにも8.30.1が登録されています。使えない環境では、[GitHubリリース](https://github.com/gitleaks/gitleaks/releases/tag/v8.30.1)の`gitleaks_8.30.1_windows_x64.zip`を展開してPATHに置きます。ARM版・32bit版も同じページにあります。 ``` winget install Gitleaks.Gitleaks # または Scoop scoop install gitleaks # 導入後の確認 gitleaks version ``` ### macOSとDockerでの導入 macOSはHomebrew（2026年10月時点のstableは8.30.1）、環境を汚したくない場合はDockerイメージを使い、対象はボリュームマウントで渡します。 ``` brew install gitleaks # Docker（GitHub Container Registry。Docker Hub は zricethezav/gitleaks） docker pull ghcr.io/gitleaks/gitleaks:latest docker run -v ${PWD}:/path ghcr.io/gitleaks/gitleaks:latest git -v /path ``` ### Ubuntuのapt版はLTSで8.16.0のまま Ubuntuでは、aptで導入するgitleaksのバージョンに注意が必要です。[Launchpadの公開パッケージ](https://launchpad.net/ubuntu/+source/gitleaks)を見ると、Ubuntu 24.04 LTSと26.04 LTSのgitleaksは**8.16.0**（2023年2月公開の版）です。2026年10月15日にリリースされたUbuntu 26.10でようやく8.26.0になりました。Debianも安定版のtrixieは8.16.0で、8.26.0はsidとforkyに限られます。 8.16.0はコマンドを再編したv8.19.0より前なので、LTSで`apt install gitleaks`した環境では`gitleaks git`も`gitleaks dir`も「unknown command」で失敗します。`[[rules.allowlists]]`（v8.21.0）や`targetRules`（v8.25.0）も解釈できず、設定ファイルを共有すると環境ごとに挙動が割れます。26.10の8.26.0でもAnthropic APIキーなどv8.28.0以降のルールは入っていないため、リリースのtar.gzで版を揃えてください。 ``` VER=8.30.1 BASE="https://github.com/gitleaks/gitleaks/releases/download/v${VER}" # -O で元のファイル名のまま保存する（-o で名前を変えると照合が素通りする） curl -sSLO "${BASE}/gitleaks_${VER}_linux_x64.tar.gz" curl -sSLO "${BASE}/gitleaks_${VER}_checksums.txt" # 照合に失敗したら以降を実行しない（&& でつなぐ） sha256sum -c "gitleaks_${VER}_checksums.txt" --ignore-missing \ && tar -xzf "gitleaks_${VER}_linux_x64.tar.gz" gitleaks \ && sudo install -m 0755 gitleaks /usr/local/bin/gitleaks \ && gitleaks version ``` `-o`で保存名を変えると、チェックサムファイルの記載名と一致せず`--ignore-missing`で全件が飛ばされ、照合が1件も走らないまま進みます。 ## .gitleaks.tomlによるルール定義 ### 設定ファイルの探索順と既定ルールの継承 設定の読み込み順は、`--config`（`-c`）で指定したパス、環境変数`GITLEAKS_CONFIG`、設定内容そのものを渡す`GITLEAKS_CONFIG_TOML`、対象パス直下の`.gitleaks.toml`の4段階です。どれも無ければ内蔵の既定設定です。 自前の設定でも既定ルールは`extend`で引き継ぎ、誤検知の多いルールだけを`disabledRules`で外します。ただし検証ではAWSのシークレットアクセスキーを拾ったのが汎用の`generic-api-key`でした。誤検知源の筆頭ですが本物も拾うので、外す前に中身を確認してください。 ``` [extend] useDefault = true disabledRules = ["generic-api-key"] ``` ### 独自ルールの必須項目とエントロピー閾値 独自ルールは`[[rules]]`で追加します。必須なのは`id`と、`regex`または`path`のどちらかです。両方無いと読み込みが失敗します。どのキャプチャグループを秘密情報とみなすかは`secretGroup`で指定し、`entropy`に閾値を与えるとその値未満のマッチは捨てられます。正規表現はGoの標準エンジンなので先読み（lookahead）は書けません。 ``` [[rules]] id = "internal-service-token" description = "社内サービスの発行トークン" regex = '''itk_[a-zA-Z0-9]{32}''' secretGroup = 0 entropy = 3.5 keywords = ["itk_"] ``` v8.28.0では、近く（`withinLines`・`withinColumns`）に別ルールの一致があるときだけ報告する複合ルールも入りました。 ### v8.21.0で複数形になったallowlists ルール単位の除外は、v8.21.0（2024年10月）で`[rules.allowlist]`から`[[rules.allowlists]]`へ変わりました。複数の除外条件を並べられ、どれか1つに一致すれば無視されます。`condition`はOR（既定）かANDで、`regexTarget`に`line`などを指定すると行全体で判定します。 ``` [[rules]] id = "internal-service-token" regex = '''itk_[a-zA-Z0-9]{32}''' [[rules.allowlists]] description = "テスト用フィクスチャのダミー値" condition = "AND" paths = ['''^tests/fixtures/'''] regexes = ['''itk_0{32}'''] [[rules.allowlists]] description = "移行前に失効済みの過去コミット" commits = ["418edf165dbb63d6f46993ae8f8818ffd87ea582"] ``` ロックファイルやテストデータのように複数ルールへ効かせる除外は、ファイル直下のグローバル`[[allowlists]]`に`targetRules`（v8.25.0）で対象idを列挙してまとめます。 ## 誤検知の抑制と既存検出の切り分け ### .gitleaksignoreへのFingerprint登録 個別の検出だけを黙らせるのが`.gitleaksignore`で、1行に1件、出力のFingerprintを書きます。検証ではgithub-patの1件だけが報告から消えました。 ``` 9db1f2ad9f4539cd19f0e4a192be270a24fb7e34:deploy.sh:github-pat:1 ``` `dir`でスキャンした結果にはコミットが無いので、「ファイル:ルールID:行番号」の3要素になります。場所は`-i`で変えられます。キーに行番号を含むので行がずれると除外が外れ、公式READMEもFingerprintを「experimental」と注記しています。長期の除外はallowlistに寄せてください。 ### gitleaks:allowコメントとbaselineの使い分け ソース側で明示したいときは、該当行に`gitleaks:allow`というコメントを書けば無視されます。監査時は`--ignore-gitleaks-allow`でこの抜け道を塞げます。 既存リポジトリに入れた初日に数百件が出る場合は、1件ずつ潰すより**baseline**が現実的です。`--report-path`で現状のレポートを出し、以後は`--baseline-path`で指定すると、レポートにある既存の検出は無視され、新しく増えた分だけが報告されます。 ``` # 現状をベースラインとして固定 gitleaks git --report-path gitleaks-report.json # 以後は新規検出だけを報告 gitleaks git --baseline-path gitleaks-report.json --report-path findings.json ``` 恒久的な仕様ならallowlist、単発の例外なら`.gitleaksignore`、導入時の一括棚上げならbaselineです。どれも本物の漏洩を見落とす経路になりえます。誤検知との付き合い方は[静的コード解析の誤検知と限界｜レビュー・テストとの責任分担](/tech/details/7475/)の考え方がそのまま当てはまります。 ### 本物を検出したときの対処順序 誤検知でないと分かったら、**最優先は当該キーの失効とローテーションで、Gitの履歴書き換えは後回しです。**コミットした時点で鍵は外に出たと見なすべきで、非公開リポジトリでもクローン・フォーク・CIログ・手元の複製を通じて残っている可能性が消えないためです。SaaSに預けたAPIキーでも順序は同じで、新しいキーへ切り替えたあと古いキーが本当に拒否されるかを確かめる手順は[Studio不正アクセスの記事](/tech/details/18389/)にまとめています。 履歴の書き換え（`git filter-repo`など）は失効を済ませてからの後処理です。書き換えた地点以降のコミットハッシュが変わるため共同作業者への影響が大きく、それ自体は漏洩を止めません。 ## pre-commitフックとGitHub Actionsへの組み込み ### pre-commitフレームワーク経由の導入 コミット前に止めるなら、Gitフックを自作するよりpre-commitフレームワークを使うほうが管理が楽です。`.git/hooks`に直接書いたフックはリポジトリで共有されませんが、次の設定をリポジトリ直下の`.pre-commit-config.yaml`に置けば、各自が`pre-commit install`を実行するだけで同じ検査を持てます。revの更新は`pre-commit autoupdate`で行います。 ``` repos: - repo: https://github.com/gitleaks/gitleaks rev: v8.30.1 hooks: - id: gitleaks ``` 検出するとコミットは失敗します。緊急時にこのフックだけ飛ばすなら`SKIP=gitleaks git commit -m "..."`のように環境変数で指定します。フックは開発者側で外せるので、同じ検査をCIでも回します。 ### gitleaks-action v3への移行と組織アカウントのライセンス GitHub Actionsでは公式の[gitleaks-action](https://github.com/gitleaks/gitleaks-action)を使います。現行はv3.0.0（2026年5月30日公開）で、変更点は実行環境をNode 20からNode 24へ移したことだけです。READMEは、2026年9月16日にNode 20がGitHubホストランナーから削除された時点で**v2はオプトアウトの設定に関係なく動かなくなる**と明記しています。既存のワークフローは`@v3`への1行修正と`actions/checkout`のv6化を済ませてください。セルフホストランナーはv2.327.1以上が必要です。 `fetch-depth: 0`で履歴を取得します。浅いクローンでは、取得範囲外にある過去の鍵を検査できません。ただしv3.0.0のソースでは、push・pull\_requestの実行は対象コミットの範囲に絞られ、範囲指定が付かないのはscheduleなどそれ以外のイベントです。下の例でcronの定期実行を併用しているのは、全履歴の検査をそちらで担わせるためです。 ``` name: gitleaks on: pull_request: push: schedule: - cron: "0 4 * * *" jobs: scan: runs-on: ubuntu-latest steps: - uses: actions/checkout@v6 with: fetch-depth: 0 - uses: gitleaks/gitleaks-action@v3 env: GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} GITLEAKS_LICENSE: ${{ secrets.GITLEAKS_LICENSE }} GITLEAKS_VERSION: 8.30.1 ``` つまずきやすいのは`GITLEAKS_LICENSE`です。**組織（Organization）アカウント配下のリポジトリをスキャンする場合はライセンスキーが必須**で、個人アカウントのリポジトリでは不要です。キーはgitleaks.ioのフォームに名前・メール・会社名を入れると無料で届きます。CLI本体はMITでも、Action自体はv2.0.0以降MITではない独自ライセンスです。 見落としやすいのがActionが使う本体の版です。v3.0.0のソースでは`GITLEAKS_VERSION`を省くと8.24.3が使われるため、上の例のように明示してローカルと揃えます。ジョブ全体の組み方は[GitHub Actionsでビルド・自動テストを設定する方法｜CI/CDワークフローの作り方](/tech/details/2497/)の構成にこのステップを足す形が扱いやすく、CIへの組み込みを社外に任せる場合は[DevOps・CI/CD導入支援](/service/system/devops/)でも相談を受けています。 ## Betterleaksとは：gitleaksとの違いと移行の判断 [Betterleaks](https://github.com/betterleaks/betterleaks)は、gitleaksの作者を含むメンバーが2026年2月に立ち上げた後継のシークレットスキャナーです。MITライセンスで、Aikido Securityがスポンサーです。gitleaksのREADME冒頭は「Gitleaks is feature complete」とし、今後はセキュリティ修正のみと明記しています。gitleaksはv8.30.1以降7か月リリースが無い一方、Betterleaksは2026年9月29日にv1.9.0、10月7日にv2.0.0-rc.2を出しています。 ### Betterleaks v1.9.0の設定・ignore互換性 1.9.0（Homebrew・wingetの`Betterleaks.Betterleaks`で入る）を同じ検証リポジトリにかけました。`git`・`dir`・`stdin`がそのまま使え、検出3件・終了コード1も同じです。リポジトリ直下に置いた`.gitleaks.toml`と`.gitleaksignore`も読み込み、github-patを報告から外しました。JSONレポートはgitleaksの18項目をすべて含み、追加は`Attributes`・`ValidationStatus`・`ValidationReason`だけです。 | 項目 | gitleaks 8.30.1 | Betterleaks 1.9.0 | | ------------------------------ | --------------- | ----------------------------- | | 既定ルール数 | 222 | 463（うち218に検証式） | | .gitleaks.toml・.gitleaksignore | 読む | 読む（.betterleaks.tomlも可） | | AWSのIDとシークレット | 別々に2件 | 1件に束ねて報告 | | `password = "changeme"` | 検出なし | generic-password（信頼度low） | | zipの中身 | 既定で読まない | 既定で8段まで読む | | 鍵の有効性検証 | なし | `--validation`で実行 | | スキャン対象の追加分 | なし | GitHub・GitLab・S3・Hugging Face | 件数は同じ3件でも中身が違います。AWSのIDとシークレットは1件に束ねられ、代わりに`password = "changeme"`が信頼度lowで拾われました。`--confidence high`を付けると2件です。 ### 鍵の有効性検証と信頼度の追加 Betterleaksの最大の追加機能は、見つけた鍵を対象サービスのAPIに投げて有効かを確かめる検証です。検証の手順はルールごとに[Expr](https://expr-lang.org/)の式で書かれており（以前のCEL形式の式も互換のため受け付けます）、github-patなら`https://api.github.com/user`を呼んで200が返るかを見ます。検証リポジトリで`--validation`を付けると、乱数で作ったGitHubトークンは「invalid（Unauthorized）」、AWSキーはSTSのエラー`InvalidClientTokenId`で「invalid」と判定されました。 ``` # 有効な鍵が見つかったときだけジョブを失敗させる betterleaks git --validation --validation-status valid . ``` この指定では、無効と判定された鍵しか無い検証リポジトリの終了コードは0でした。大量の過去検出から有効な鍵を優先処理する用途に使えます。ただし、validだけへの絞り込みでは検証エラー・判定不能・検証非対応の検出も報告対象から外れるため、通常の漏洩防止ゲートとは分けて実行します。ただし見つけた値を外部サービスへ実際に送るので、社外通信を制限したCIや送信自体を監査対象にする組織では既定のオフのまま使ってください。 ### v2（RC）で互換が切れる点 注意すべきは開発中のv2です。[公式の移行ガイド](https://github.com/betterleaks/betterleaks/blob/main/docs/v2%5Fmigration.md)によると、v2では次の互換が切れます。 - `.betterleaks.toml`・`.gitleaks.toml`の自動探索をやめ、`--config`か環境変数での明示が必要になる（`GITLEAKS_CONFIG`は`BETTERLEAKS_CONFIG`へ改名） - 位置ベースのFingerprintと`.gitleaksignore`の読み込みを廃止し、秘密値そのもののSHA-256で除外する方式に変わる - `--baseline-path`と、CSV・JUnit・SARIF・templateのレポート出力を廃止する（JSONは構造が変わる） - `-v`の意味が「詳細表示」から「有効性検証の実行」に変わる SARIFでCode Scanningに載せる構成やbaselineで棚上げしている構成は、v2ではそのまま動きません。READMEによれば、v2の安定版が出ると公式tapのcaskとDockerの`latest`タグはv2に移ります。**gitleaksからの置き換えはv1系（1.9.0）に固定して行い、v2は安定版で移行手順を検証してから上げる**のが安全です。 ``` # v1系に固定して導入する（Homebrewの公式tap。コマンド名は betterleaks-v1） brew install --cask betterleaks/tap/betterleaks@1 # Dockerならv1タグ docker pull ghcr.io/betterleaks/betterleaks:v1 ``` ## trufflehog・git-secretsとの使い分け ### trufflehogとの検出方針とライセンスの違い 比較対象の一つが、有効性検証に対応するtrufflehogです。最大の違いは検出後の扱いで、trufflehogは既定で鍵の有効性を検証し、`--results=verified`は有効と確認できた結果だけを出力する指定です。外部APIによる検証を止めるには`--no-verification`を指定します。gitleaksにはこの検証が無く、Betterleaksは逆に既定オフで持ち込みました。trufflehogはS3やDockerイメージも走査できます。 実務で重いのはライセンスです。trufflehogはAGPL-3.0で、CIで呼ぶだけなら通常は問題ありませんが、改変して自社サービスへ組み込むなら法務確認が要ります。 | ツール | ライセンス | 最新版（2026年10月時点） | 特徴 | | -------------- | ---------- | ---------------- | ---------------- | | gitleaks | MIT | v8.30.1（2026-03） | 機能追加は終了 | | Betterleaks | MIT | v1.9.0（2026-09） | gitleaks互換・有効性検証 | | trufflehog | AGPL-3.0 | v3.99.2（2026-10） | 有効性検証・走査対象が広い | | git-secrets | Apache-2.0 | タグ1.3.0（リリース無し） | AWS製・フック特化 | | detect-secrets | Apache-2.0 | v1.5.0（2024-05） | Yelp製・baseline運用 | ### git-secrets・detect-secrets・GitHub側機能との住み分け git-secretsはGitHubリリースが無く最終更新が2025年9月、detect-secretsはv1.5.0（2024年5月）以降リリースが無く、新規採用の理由は薄いのが実情です。 CLIとは別に、GitHub側にもSecret ScanningとPush Protectionがあります。パートナー連携で漏洩トークンの自動失効まで届くので、手元とCIで止めるgitleaksと、取りこぼしを拾うGitHub側を重ねるのが現実的です。有償機能の範囲は[GitHub Advanced Securityとは｜Secret Protection月19ドル・Code Security月30ドルの料金と課金の数え方](/tech/details/5211/)で確認できます。秘密情報ではなくコードの脆弱なパターンを探したい場合は、[Semgrep](/tech/details/12476/)のようなSASTツールの守備範囲です。 ## 「feature complete」宣言後のgitleaks採用判断 **既にgitleaksをCIやpre-commitで回している組織は、今すぐ乗り換える必要はありません。**ルール追加が止まっても既存の検出は壊れず、セキュリティ修正は続きます。やるべきはgitleaks-actionのv3化と`GITLEAKS_VERSION`での版固定です。 **これから新規に入れるなら、gitleaks単体に寄せるのは勧めません。**新しいSaaSのトークン書式は増え続けるのに、ルール追加は止まっているためです。社内でルールを足し続ける体制が無いなら、gitleaksの設定をそのまま読めるBetterleaks 1.9.0を第一候補にしてください。 避けるべきは、v2のRCを本番CIに入れることと、誤検知を誰が捌くかを決めずに導入することです。後者は検出が放置されて形骸化します。開発工程全体での位置付けは[ソフトウェアサプライチェーンセキュリティの記事](/tech/details/16232/)、静的解析の種類の整理は[SASTとは？DAST・SCAとの違い](/tech/details/15880/)を参照してください。 ## よくある質問 ### gitleaks detectはもう使えないのですか？ 動きます。v8.19.0で非推奨になり`--help`から外れただけで、v8.30.1でも`gitleaks detect --source`は`git`と同じ結果を返しました。新しく書く設定は`git`・`dir`・`stdin`に揃えます。Ubuntu 24.04 LTS・26.04 LTSのapt版8.16.0では、履歴検査に`detect`、未コミット差分の検査に`protect`を使います。 ### gitleaksのライセンスは何ですか？商用利用に費用はかかりますか？ CLI本体はMITライセンスで、商用利用を含めて無償です。手続きが要るのはGitHub Actions版で、組織アカウント配下のリポジトリをスキャンするときは`GITLEAKS_LICENSE`の登録が必要です。キーはgitleaks.ioで無料で発行されます。 ### Windowsにgitleaksを入れるにはどうすればよいですか？ `winget install Gitleaks.Gitleaks`が最短で、Scoopのmainバケットにも同じ8.30.1があります。どちらも使えない環境では、リリースページの`windows_x64`のzipを展開し、PATHの通ったフォルダに置いてください。 ### gitleaksとBetterleaksはどちらを使うべきですか？ 既存のgitleaks運用はそのままで構いません。新規導入で、ルールの追加や鍵の有効性検証を求めるならBetterleaksの安定版1.9.0です。v2は`.gitleaksignore`やSARIF出力が廃止されるので、RCは本番に入れないでください。 ### gitleaksとtrufflehogはどちらを選ぶべきですか？ 過去の履歴から「今も有効な鍵」を優先して洗い出したい、S3やDockerイメージも見たいならtrufflehogです。CIとpre-commitに軽く常駐させ、MITライセンスで法務確認の負荷を避けたいならgitleaksかBetterleaksが向きます。日常のゲートと定期的な棚卸しで使い分ける組み合わせも取れます。 ## 関連記事 - [GitHub Advanced Securityとは｜Secret Protection月19ドル・Code Security月30ドルの料金と課金の数え方](/tech/details/5211/) - [Semgrepとは？使い方・ルールの書き方・料金と無料版の検出範囲【v1.180で実測】](/tech/details/12476/) - [SASTとは？DAST・SCAとの違いとCI/CDへの組み込み・導入判断を実装視点で解説](/tech/details/15880/) - [GitHub Actionsでビルド・自動テストを設定する方法｜CI/CDワークフローの作り方](/tech/details/2497/) - [actionlintとは？GitHub Actionsワークフローの静的解析ツールの使い方・インストール・設定](/tech/details/10397/) --- 出典: [gitleaksとは？使い方・設定とBetterleaksへの移行判断【v8.30.1で実測】]()（株式会社一創）