Gitleaks

Gitleaks

┌─○───┐
│ │╲  │
│ │ ○ │
│ ○ ░ │
└─░───┘

警告

Gitleaks は機能が完成しています。Gitleaks に新機能をマージする予定はありません。今後のリリースはセキュリティパッチのみとなります。今後は Betterleaks に注力します。

Gitleaks は、git リポジトリやファイル、また stdin 経由で渡された任意のデータに含まれるパスワード、API キー、トークンなどのシークレットを検出するツールです。検出エンジンの仕組みについて詳しく知りたい場合は、こちらのブログをご覧ください：Regex is (almost) all you need。

➜  ~/code(master) gitleaks git -v

    ○
    │╲
    │ ○
    ○ ░
    ░    gitleaks


Finding:     "export BUNDLE_ENTERPRISE__CONTRIBSYS__COM=cafebabe:deadbeef",
Secret:      cafebabe:deadbeef
RuleID:      sidekiq-secret
Entropy:     2.609850
File:        cmd/generate/config/rules/sidekiq.go
Line:        23
Commit:      cd5226711335c68be1e720b318b7bc3135a30eb2
Author:      John
Email:       [email protected]
Date:        2022-08-03T12:31:40Z
Fingerprint: cd5226711335c68be1e720b318b7bc3135a30eb2:cmd/generate/config/rules/sidekiq.go:sidekiq-secret:23

はじめに

Gitleaks は Homebrew、Docker、または Go を使ってインストールできます。Gitleaks は、リリースページから多くの一般的なプラットフォームや OS 向けのバイナリ形式でも入手できます。また、リポジトリに直接 pre-commit フックとして導入したり、Gitleaks-Action を使って GitHub アクションとして導入したりできます。

インストール

# MacOS
brew install gitleaks

# Docker (DockerHub)
docker pull zricethezav/gitleaks:latest
docker run -v ${path_to_host_folder_to_scan}:/path zricethezav/gitleaks:latest [COMMAND] [OPTIONS] [SOURCE_PATH]

# Docker (ghcr.io)
docker pull ghcr.io/gitleaks/gitleaks:latest
docker run -v ${path_to_host_folder_to_scan}:/path ghcr.io/gitleaks/gitleaks:latest [COMMAND] [OPTIONS] [SOURCE_PATH]

# From Source (make sure `go` is installed)
git clone https://github.com/gitleaks/gitleaks.git
cd gitleaks
make build

Pre-Commit

1. https://pre-commit.com/#install から pre-commit をインストールします。

2. リポジトリのルートに .pre-commit-config.yaml ファイルを作成し、次の内容を記述します。

   repos:
     - repo: https://github.com/gitleaks/gitleaks
       rev: v8.24.2
       hooks:
         - id: gitleaks
   

   gitleaks をネイティブに実行するか、公式 Docker イメージを使って gitleaks を実行するには、gitleaks-docker pre-commit ID を使用します。

3. pre-commit autoupdate を実行して、設定をリポジトリの最新バージョンに自動更新します。

4. pre-commit install でインストールします。

5. これで準備完了です。

➜ git commit -m "this commit contains a secret"
Detect hardcoded secrets.................................................Failed

注：gitleaks の pre-commit フックを無効にするには、コミットコマンドの先頭に SKIP=gitleaks を付けます。 これにより、gitleaks の実行がスキップされます。

➜ SKIP=gitleaks git commit -m "skip gitleaks check"
Detect hardcoded secrets................................................Skipped

使い方

Gitleaks scans code, past or present, for secrets

Usage:
  gitleaks [command]

Available Commands:
  completion  Generate the autocompletion script for the specified shell
  dir         scan directories or files for secrets
  git         scan git repositories for secrets
  help        Help about any command
  stdin       detect secrets from stdin
  version     display gitleaks version

Flags:
  -b, --baseline-path string          path to baseline with issues that can be ignored
  -c, --config string                 config file path
                                      order of precedence:
                                      1. --config/-c
                                      2. env var GITLEAKS_CONFIG
                                      3. env var GITLEAKS_CONFIG_TOML with the file content
                                      4. (target path)/.gitleaks.toml
                                      If none of the four options are used, then gitleaks will use the default config
      --diagnostics string            enable diagnostics (http OR comma-separated list: cpu,mem,trace). cpu=CPU prof, mem=memory prof, trace=exec tracing, http=serve via net/http/pprof
      --diagnostics-dir string        directory to store diagnostics output files when not using http mode (defaults to current directory)
      --enable-rule strings           only enable specific rules by id
      --exit-code int                 exit code when leaks have been encountered (default 1)
  -i, --gitleaks-ignore-path string   path to .gitleaksignore file or folder containing one (default ".")
  -h, --help                          help for gitleaks
      --ignore-gitleaks-allow         ignore gitleaks:allow comments
  -l, --log-level string              log level (trace, debug, info, warn, error, fatal) (default "info")
      --max-archive-depth int         allow scanning into nested archives up to this depth (default "0", no archive traversal is done)
      --max-decode-depth int          allow recursive decoding up to this depth (default "0", no decoding is done)
      --max-target-megabytes int      files larger than this will be skipped
      --no-banner                     suppress banner
      --no-color                      turn off color for verbose output
      --redact uint[=100]             redact secrets from logs and stdout. To redact only parts of the secret just apply a percent value from 0..100. For example --redact=20 (default 100%)
  -f, --report-format string          output format (json, csv, junit, sarif, template)
  -r, --report-path string            report file
      --report-template string        template file used to generate the report (implies --report-format=template)
      --timeout int                   set a timeout for gitleaks commands in seconds (default "0", no timeout is set)
  -v, --verbose                       show verbose output from scan
      --version                       version for gitleaks

Use "gitleaks [command] --help" for more information about a command.

コマンド

⚠️ v8.19.0 では変更が導入され、detect と protect は非推奨になりました。これらのコマンドは引き続き使用できますが、--help メニューには表示されません。コマンドを簡単に置き換える方法については、この gist をご覧ください。 v8.19.0 によって既存のコマンド（detect／protect）が動作しなくなった場合は、issue を作成してください。

スキャンモードは git、dir、stdin の 3 つです。

Git

git コマンドを使うと、ローカルの git リポジトリをスキャンできます。内部では、gitleaks は git log -p コマンドを使ってパッチをスキャンします。 log-opts オプションを使って、git log -p の動作を設定できます。 たとえば、コミット範囲を指定して gitleaks を実行する場合は、次のコマンドを使用します：gitleaks git -v --log-opts="--all commitA..commitB" path_to_repo。詳しくは git log のドキュメントをご覧ください。 位置引数で対象が指定されていない場合、gitleaks は現在の作業ディレクトリを git リポジトリとしてスキャンしようとします。

Dir

dir（files、directory などのエイリアスがあります）コマンドを使用すると、ディレクトリやファイルをスキャンできます。例：gitleaks dir -v path_to_directory_or_file。 位置引数として対象が指定されていない場合、gitleaks は現在の作業ディレクトリをスキャンします。

Stdin

stdin コマンドを使って、データを gitleaks にストリームすることもできます。例：cat some_file | gitleaks -v stdin

ベースラインの作成

大規模なリポジトリや長い履歴を持つリポジトリをスキャンする場合、ベースラインを使用すると便利です。ベースラインを使用すると、 gitleaks はベースラインに含まれる古い検出結果を無視します。ベースラインには gitleaks のレポートを使用できます。gitleaks のレポートを作成するには、--report-path パラメーターを指定して gitleaks を実行します。

gitleaks git --report-path gitleaks-report.json # This will save the report in a file called gitleaks-report.json

ベースラインを作成したら、detect コマンドを再実行する際に適用できます。

gitleaks git --baseline-path gitleaks-report.json --report-path findings.json

--baseline-path パラメーターを指定して detect コマンドを実行すると、レポート出力（findings.json）には新しい問題のみが含まれます。

Pre-Commit フック

サンプルの pre-commit.py スクリプトを .git/hooks/ ディレクトリにコピーすると、Gitleaks を pre-commit フックとして実行できます。

設定の読み込み

優先順位は次のとおりです。

1. --config/-c オプション：

   gitleaks git --config /home/dev/customgitleaks.toml .
   

2. ファイルパスを指定する環境変数 GITLEAKS_CONFIG：

   export GITLEAKS_CONFIG="/home/dev/customgitleaks.toml"
   gitleaks git .
   

3. ファイルの内容を指定する環境変数 GITLEAKS_CONFIG_TOML：

   export GITLEAKS_CONFIG_TOML=`cat customgitleaks.toml`
   gitleaks git .
   

4. 対象パス内の .gitleaks.toml ファイル：

   gitleaks git .
   

4 つのオプションのいずれも使用されない場合、gitleaks はデフォルト設定を使用します。

設定

Gitleaks は、独自のシークレット検出ルールを記述するための設定形式を提供しています。

# Title for the gitleaks configuration file.
title = "Custom Gitleaks configuration"

# You have basically two options for your custom configuration:
#
# 1. define your own configuration, default rules do not apply
#
#    use e.g., the default configuration as starting point:
#    https://github.com/gitleaks/gitleaks/blob/master/config/gitleaks.toml
#
# 2. extend a configuration, the rules are overwritten or extended
#
#    When you extend a configuration the extended rules take precedence over the
#    default rules. I.e., if there are duplicate rules in both the extended
#    configuration and the default configuration the extended rules or
#    attributes of them will override the default rules.
#    Another thing to know with extending configurations is you can chain
#    together multiple configuration files to a depth of 2. Allowlist arrays are
#    appended and can contain duplicates.

# useDefault and path can NOT be used at the same time. Choose one.
[extend]
# useDefault will extend the default gitleaks config built in to the binary
# the latest version is located at:
# https://github.com/gitleaks/gitleaks/blob/master/config/gitleaks.toml
useDefault = true
# or you can provide a path to a configuration to extend from.
# The path is relative to where gitleaks was invoked,
# not the location of the base config.
# path = "common_config.toml"
# If there are any rules you don't want to inherit, they can be specified here.
disabledRules = [ "generic-api-key"]

# An array of tables that contain information that define instructions
# on how to detect secrets
[[rules]]
# Unique identifier for this rule
id = "awesome-rule-1"

# Short human-readable description of the rule.
description = "awesome rule 1"

# Golang regular expression used to detect secrets. Note Golang's regex engine
# does not support lookaheads.
regex = '''one-go-style-regex-for-this-rule'''

# Int used to extract secret from regex match and used as the group that will have
# its entropy checked if `entropy` is set.
secretGroup = 3

# Float representing the minimum shannon entropy a regex group must have to be considered a secret.
entropy = 3.5

# Golang regular expression used to match paths. This can be used as a standalone rule or it can be used
# in conjunction with a valid `regex` entry.
path = '''a-file-path-regex'''

# Keywords are used for pre-regex check filtering. Rules that contain
# keywords will perform a quick string compare check to make sure the
# keyword(s) are in the content being scanned. Ideally these values should
# either be part of the identiifer or unique strings specific to the rule's regex
# (introduced in v8.6.0)
keywords = [
  "auth",
  "password",
  "token",
]

# Array of strings used for metadata and reporting purposes.
tags = ["tag","another tag"]

    # ⚠️ In v8.21.0 `[rules.allowlist]` was replaced with `[[rules.allowlists]]`.
    # This change was backwards-compatible: instances of `[rules.allowlist]` still  work.
    #
    # You can define multiple allowlists for a rule to reduce false positives.
    # A finding will be ignored if _ANY_ `[[rules.allowlists]]` matches.
    [[rules.allowlists]]
    description = "ignore commit A"
    # When multiple criteria are defined the default condition is "OR".
    # e.g., this can match on |commits| OR |paths| OR |stopwords|.
    condition = "OR"
    commits = [ "commit-A", "commit-B"]
    paths = [
      '''go\.mod''',
      '''go\.sum'''
    ]
    # note: stopwords targets the extracted secret, not the entire regex match
    # like 'regexes' does. (stopwords introduced in 8.8.0)
    stopwords = [
      '''client''',
      '''endpoint''',
    ]

    [[rules.allowlists]]
    # The "AND" condition can be used to make sure all criteria match.
    # e.g., this matches if |regexes| AND |paths| are satisfied.
    condition = "AND"
    # note: |regexes| defaults to check the _Secret_ in the finding.
    # Acceptable values for |regexTarget| are "secret" (default), "match", and "line".
    regexTarget = "match"
    regexes = [ '''(?i)parseur[il]''' ]
    paths = [ '''package-lock\.json''' ]

# You can extend a particular rule from the default config. e.g., gitlab-pat
# if you have defined a custom token prefix on your GitLab instance
[[rules]]
id = "gitlab-pat"
# all the other attributes from the default rule are inherited

    [[rules.allowlists]]
    regexTarget = "line"
    regexes = [ '''MY-glpat-''' ]


# ⚠️ In v8.25.0 `[allowlist]` was replaced with `[[allowlists]]`.
#
# Global allowlists have a higher order of precedence than rule-specific allowlists.
# If a commit listed in the `commits` field below is encountered then that commit will be skipped and no
# secrets will be detected for said commit. The same logic applies for regexes and paths.
[[allowlists]]
description = "global allow list"
commits = [ "commit-A", "commit-B", "commit-C"]
paths = [
  '''gitleaks\.toml''',
  '''(.*?)(jpg|gif|doc)'''
]
# note: (global) regexTarget defaults to check the _Secret_ in the finding.
# Acceptable values for regexTarget are "match" and "line"
regexTarget = "match"
regexes = [
  '''219-09-9999''',
  '''078-05-1120''',
  '''(9[0-9]{2}|666)-\d{2}-\d{4}''',
]
# note: stopwords targets the extracted secret, not the entire regex match
# like 'regexes' does. (stopwords introduced in 8.8.0)
stopwords = [
  '''client''',
  '''endpoint''',
]

# ⚠️ In v8.25.0, `[[allowlists]]` have a new field called |targetRules|.
#
# Common allowlists can be defined once and assigned to multiple rules using |targetRules|.
# This will only run on the specified rules, not globally.
[[allowlists]]
targetRules = ["awesome-rule-1", "awesome-rule-2"]
description = "Our test assets trigger false-positives in a couple rules."
paths = ['''tests/expected/._\.json$''']

例については、デフォルトの gitleaks 設定を参照してください。デフォルト設定への貢献を希望する場合は、貢献ガイドラインに従ってください。また、高度な設定方法を解説したこちらの gitleaks ブログ記事もご覧ください。

追加設定

複合ルール（複数パートのルールまたはrequiredルール）

v8.28.0で、Gitleaksに複合ルールが導入されました。複合ルールは、単一の「プライマリ」ルールと、1つ以上の補助ルールまたはrequiredルールで構成されます。複合ルールを作成するには、プライマリルールに[[rules.required]]テーブルを追加し、idと、任意でwithinLinesやwithinColumnsの近接制約を指定します。フラグメントとは、Gitleaksが一度に処理するコンテンツのまとまり（通常はファイル、ファイルの一部、またはgit diff）です。近接マッチングを指定すると、フラグメント内の指定した範囲で補助のrequiredルールも一致した場合にのみ、プライマリルールが検出結果を報告するようになります。

近接マッチング： withinLinesフィールドとwithinColumnsフィールドを使用すると、指定した近接範囲内で補助のrequiredルールも一致した場合にのみ、プライマリルールが検出結果を報告するようになります。次のように設定できます。

• withinLines: N - 必須の検出結果がN行以内（縦方向）にある必要があります
• withinColumns: N - 必須の検出結果がN文字以内（横方向）にある必要があります
• 両方 - 長方形の検索範囲を作成します（両方の制約を満たす必要があります）
• どちらも指定しない - フラグメントレベルで照合します（必須の検出結果は同じフラグメント内のどこにあってもかまいません）

近接動作を示す図を以下に示します。

p = primary captured secret
a = auxiliary (required) captured secret
fragment = section of data gitleaks is looking at


    *Fragment-level proximity*
    Any required finding in the fragment
          ┌────────┐
   ┌──────┤fragment├─────┐
   │      └──────┬─┤     │ ┌───────┐
   │             │a│◀────┼─│✓ MATCH│
   │          ┌─┐└─┘     │ └───────┘
   │┌─┐       │p│        │
   ││a│    ┌─┐└─┘        │ ┌───────┐
   │└─┘    │a│◀──────────┼─│✓ MATCH│
   └─▲─────┴─┴───────────┘ └───────┘
     │    ┌───────┐
     └────│✓ MATCH│
          └───────┘


   *Column bounded proximity*
   `withinColumns = 3`
          ┌────────┐
   ┌────┬─┤fragment├─┬───┐
   │      └──────┬─┤     │ ┌───────────┐
   │    │        │a│◀┼───┼─│+1C ✓ MATCH│
   │          ┌─┐└─┘     │ └───────────┘
   │┌─┐ │     │p│    │   │
┌──▶│a│  ┌─┐  └─┘        │ ┌───────────┐
│  │└─┘ ││a│◀────────┼───┼─│-2C ✓ MATCH│
│  │       ┘             │ └───────────┘
│  └── -3C ───0C─── +3C ─┘
│  ┌─────────┐
│  │ -4C ✗ NO│
└──│  MATCH  │
   └─────────┘


   *Line bounded proximity*
   `withinLines = 4`
         ┌────────┐
   ┌─────┤fragment├─────┐
  +4L─ ─ ┴────────┘─ ─ ─│
   │                    │
   │              ┌─┐   │ ┌────────────┐
   │         ┌─┐  │a│◀──┼─│+1L ✓ MATCH │
   0L  ┌─┐   │p│  └─┘   │ ├────────────┤
   │   │a│◀──┴─┴────────┼─│-1L ✓ MATCH │
   │   └─┘              │ └────────────┘
   │                    │ ┌─────────┐
  -4L─ ─ ─ ─ ─ ─ ─ ─┌─┐─│ │-5L ✗ NO │
   │                │a│◀┼─│  MATCH  │
   └────────────────┴─┴─┘ └─────────┘


   *Line and column bounded proximity*
   `withinLines = 4`
   `withinColumns = 3`
         ┌────────┐
   ┌─────┤fragment├─────┐
  +4L   ┌└────────┴ ┐   │
   │            ┌─┐     │ ┌───────────────┐
   │    │       │a│◀┼───┼─│+2L/+1C ✓ MATCH│
   │         ┌─┐└─┘     │ └───────────────┘
   0L   │    │p│    │   │
   │         └─┘        │
   │    │           │   │ ┌────────────┐
  -4L    ─ ─ ─ ─ ─ ─┌─┐ │ │-5L/+3C ✗ NO│
   │                │a│◀┼─│   MATCH    │
   └───-3C────0L───+3C┴─┘ └────────────┘

複合ルールについて、最後に手短な補足です。

これは実験的な機能です！変更される可能性があるため、この機能を基盤にした新しいB2B SaaS機能を今すぐ売り込まないでください。スキャンの種類（gitかdirか）に応じたコンテキストは興味深いものです。状況を注視しています。Gitleaksはgitの履歴に追加された内容しか確認しないため、複合ルールはgitスキャンではあまり役に立たないかもしれません。gitの履歴から追加されていない内容を`required`ルールでスキャンする用途には使える可能性があります。ああ、そういえばこれはREADMEでしたね。もう黙っておきます。

gitleaks:allow

Gitleaksが検出することを承知のうえでテスト用のシークレットをコミットする場合、その行にgitleaks:allowコメントを追加すると、Gitleaksはそのシークレットを無視します。例：

class CustomClass:
    discord_client_secret = '8dyfuiRyq=vVc3RRr_edRk-fK__JItpZ'  #gitleaks:allow

.gitleaksignore

リポジトリのルートに.gitleaksignoreファイルを作成すると、特定の検出結果を無視できます。リリースv8.10.0で、GitleaksはレポートにFingerprint値を追加しました。各リーク（検出結果）には、シークレットを一意に識別するフィンガープリントがあります。このフィンガープリントを.gitleaksignoreファイルに追加すると、そのシークレットを無視できます。例については、Gitleaksの.gitleaksignoreを参照してください。注：この機能は実験的なものであり、今後変更される可能性があります。

デコード

シークレットが、正規表現だけでは見つけにくい形式でエンコードされていることがあります。gitleaksにエンコードされたテキストを自動的に検出してデコードするよう指定できるようになりました。フラグ--max-decode-depthでこの機能を有効にできます（デフォルト値の「0」は、機能がデフォルトで無効であることを意味します）。

デコードされたテキストにもエンコードされたテキストが含まれる場合があるため、再帰的なデコードにも対応しています。フラグ--max-decode-depthで再帰の上限を設定します。デコードする新しいエンコード済みテキストのセグメントがなくなると再帰は停止するため、最大深度を非常に大きく設定しても、その回数だけ処理が繰り返されるわけではありません。テキストのデコードに必要な回数だけ処理されます。全体として、デコードによるスキャン時間の増加はごくわずかです。

エンコードされたテキストの検出結果は、通常の検出結果と次の点で異なります。

• 場所は、エンコードされたテキストの範囲を示します
  • ルールがエンコードされたテキストの範囲外にも一致する場合、範囲はそれも含むように調整されます
• 一致内容とシークレットには、デコードされた値が含まれます
• decoded:<encoding>とdecode-depth:<depth>の2つのタグが追加されます

現在、次のエンコーディングに対応しています。

• percent - 印字可能なASCII文字からなるパーセントエンコード値
• hex - 32文字以上の印字可能なASCII文字からなる16進数エンコード値
• base64 - 16文字以上の印字可能なASCII文字からなるbase64エンコード値

アーカイブのスキャン

シークレットが ZIP ファイルや tarball などのアーカイブファイル内に含まれていると、見つけるのが難しい場合があります。gitleaks にアーカイブの内容を自動的に展開してスキャンするよう指示できるようになりました。フラグ --max-archive-depth を使用すると、dir と git の両方のスキャンタイプでこの機能が有効になります。デフォルト値の「0」では、この機能は無効です。

アーカイブには別のアーカイブが含まれる場合もあるため、再帰スキャンがサポートされています。フラグ --max-archive-depth は再帰の上限を設定します。新たに展開するアーカイブがなくなると再帰は停止するため、最大深度を非常に高く設定しても、その深さまで到達する可能性を設定するだけです。必要な深さまでしかスキャンされません。

アーカイブ内にあるシークレットの検出結果には、アーカイブ内のファイルパスが含まれます。内部パスは ! で区切られます。

検出結果の例（簡潔にするため一部省略）：

Finding:     DB_PASSWORD=8ae31cacf141669ddfb5da
...
File:        testdata/archives/nested.tar.gz!archives/files.tar!files/.env.prod
Line:        4
Commit:      6e6ee6596d337bb656496425fb98644eb62b4a82
...
Fingerprint: 6e6ee6596d337bb656496425fb98644eb62b4a82:testdata/archives/nested.tar.gz!archives/files.tar!files/.env.prod:generic-api-key:4
Link:        https://github.com/leaktk/gitleaks/blob/6e6ee6596d337bb656496425fb98644eb62b4a82/testdata/archives/nested.tar.gz

これは、testdata/archives/nested.tar.gz 内の archives/files.tar にある files/.env.prod. の4行目でシークレットが検出されたことを意味します。

現在サポートされている形式：

mholt の archives パッケージでサポートされている圧縮形式およびアーカイブ形式に対応しています。

レポート

Gitleaks は、json、csv、junit、sarif の各レポート形式を標準でサポートしています。

これらの形式では要件を満たせない場合は、Go の text/template .tmpl ファイルと --report-template フラグを使用して、独自のレポート形式を作成できます。テンプレートでは、Masterminds/sprig テンプレートライブラリの拡張機能を利用できます。

たとえば、次のテンプレートはカスタム JSON 出力を生成します。

# jsonextra.tmpl
[{{ $lastFinding := (sub (len . ) 1) }}
{{- range $i, $finding := . }}{{with $finding}}
    {
        "Description": {{ quote .Description }},
        "StartLine": {{ .StartLine }},
        "EndLine": {{ .EndLine }},
        "StartColumn": {{ .StartColumn }},
        "EndColumn": {{ .EndColumn }},
        "Line": {{ quote .Line }},
        "Match": {{ quote .Match }},
        "Secret": {{ quote .Secret }},
        "File": "{{ .File }}",
        "SymlinkFile": {{ quote .SymlinkFile }},
        "Commit": {{ quote .Commit }},
        "Entropy": {{ .Entropy }},
        "Author": {{ quote .Author }},
        "Email": {{ quote .Email }},
        "Date": {{ quote .Date }},
        "Message": {{ quote .Message }},
        "Tags": [{{ $lastTag := (sub (len .Tags ) 1) }}{{ range $j, $tag := .Tags }}{{ quote . }}{{ if ne $j $lastTag }},{{ end }}{{ end }}],
        "RuleID": {{ quote .RuleID }},
        "Fingerprint": {{ quote .Fingerprint }}
    }{{ if ne $i $lastFinding }},{{ end }}
{{- end}}{{ end }}
]

使用方法：

$ gitleaks dir ~/leaky-repo/ --report-path "report.json" --report-format template --report-template testdata/report/jsonextra.tmpl

スポンサー

coderabbit.ai

終了コード

漏えいが検出されたときの終了コードは、いつでも --exit-code フラグで設定できます。デフォルトの終了コードは以下のとおりです。

0 - no leaks present
1 - leaks or error encountered
126 - unknown flag

Discord に参加しましょう！