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）には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:       [email protected]
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の比較

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年前後のものです。

--sourceによる対象指定は位置引数に変わり、省略するとカレントディレクトリが対象です。protectの後継がgitleaks git --pre-commitであることは、公式の.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不正アクセス事案の全容で整理しています。

OS別のインストール手順

Windowsでのwinget・Scoop・zip導入

公式READMEはWindowsのパッケージマネージャーに触れていませんが、wingetの公式リポジトリにパッケージID Gitleaks.Gitleaksとして8.30.1が、Scoopのmainバケットにも8.30.1が登録されています。使えない環境では、GitHubリリースの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の公開パッケージを見ると、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です。どれも本物の漏洩を見落とす経路になりえます。誤検知との付き合い方は静的コード解析の誤検知と限界｜レビュー・テストとの責任分担の考え方がそのまま当てはまります。

本物を検出したときの対処順序

誤検知でないと分かったら、最優先は当該キーの失効とローテーションで、Gitの履歴書き換えは後回しです。コミットした時点で鍵は外に出たと見なすべきで、非公開リポジトリでもクローン・フォーク・CIログ・手元の複製を通じて残っている可能性が消えないためです。SaaSに預けたAPIキーでも順序は同じで、新しいキーへ切り替えたあと古いキーが本当に拒否されるかを確かめる手順はStudio不正アクセスの記事にまとめています。

履歴の書き換え（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を使います。現行は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ワークフローの作り方の構成にこのステップを足す形が扱いやすく、CIへの組み込みを社外に任せる場合はDevOps・CI/CD導入支援でも相談を受けています。

Betterleaksとは：gitleaksとの違いと移行の判断

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だけです。

件数は同じ3件でも中身が違います。AWSのIDとシークレットは1件に束ねられ、代わりにpassword = "changeme"が信頼度lowで拾われました。--confidence highを付けると2件です。

鍵の有効性検証と信頼度の追加

Betterleaksの最大の追加機能は、見つけた鍵を対象サービスのAPIに投げて有効かを確かめる検証です。検証の手順はルールごとにExprの式で書かれており（以前の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です。公式の移行ガイドによると、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で呼ぶだけなら通常は問題ありませんが、改変して自社サービスへ組み込むなら法務確認が要ります。

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ドルの料金と課金の数え方で確認できます。秘密情報ではなくコードの脆弱なパターンを探したい場合は、SemgrepのようなSASTツールの守備範囲です。

「feature complete」宣言後のgitleaks採用判断

既にgitleaksをCIやpre-commitで回している組織は、今すぐ乗り換える必要はありません。ルール追加が止まっても既存の検出は壊れず、セキュリティ修正は続きます。やるべきはgitleaks-actionのv3化とGITLEAKS_VERSIONでの版固定です。

これから新規に入れるなら、gitleaks単体に寄せるのは勧めません。新しいSaaSのトークン書式は増え続けるのに、ルール追加は止まっているためです。社内でルールを足し続ける体制が無いなら、gitleaksの設定をそのまま読めるBetterleaks 1.9.0を第一候補にしてください。

避けるべきは、v2のRCを本番CIに入れることと、誤検知を誰が捌くかを決めずに導入することです。後者は検出が放置されて形骸化します。開発工程全体での位置付けはソフトウェアサプライチェーンセキュリティの記事、静的解析の種類の整理はSASTとは？DAST・SCAとの違いを参照してください。

よくある質問

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ドルの料金と課金の数え方
• Semgrepとは？使い方・ルールの書き方・料金と無料版の検出範囲【v1.180で実測】
• SASTとは？DAST・SCAとの違いとCI/CDへの組み込み・導入判断を実装視点で解説
• GitHub Actionsでビルド・自動テストを設定する方法｜CI/CDワークフローの作り方
• actionlintとは？GitHub Actionsワークフローの静的解析ツールの使い方・インストール・設定