본문으로 건너뛰기

© 2026 Molayo

GitHub릴리즈2026. 05. 07. 02:56

Gitleaks: Git 저장소 및 파일에서 비밀 정보 탐지 도구

요약

Gitleaks는 Git 저장소, 파일, 그리고 표준 입력(stdin)을 통해 전달되는 모든 데이터에서 비밀번호, API 키, 토큰과 같은 민감한 정보를 탐지하는 보안 도구입니다. 이 도구는 로컬 Git 레포지토리 스캔(`git`), 디렉터리/파일 스캔(`dir`), 또는 스트림 데이터를 이용한 스캔(`stdin`) 등 다양한 방식으로 작동합니다. 개발 워크플로우에 통합하기 쉽도록 pre-commit hook, GitHub Action 등으로 구현할 수 있어 코드가 커밋되기 전에 보안 취약점을 사전에 방지하는 데 매우 효과적입니다.

핵심 포인트

  • Gitleaks는 비밀번호, API 키, 토큰 등 민감 정보를 탐지하여 코드 유출을 방지합니다.
  • 세 가지 주요 스캔 모드(`git`, `dir`, `stdin`)를 제공하여 다양한 환경에서 보안 검사가 가능합니다.
  • pre-commit hook 또는 GitHub Action으로 쉽게 통합할 수 있어 개발 초기 단계부터 보안을 강화할 수 있습니다.
  • 로컬 Git 레포지토리의 커밋 히스토리까지 스캔할 수 있는 강력한 기능을 제공합니다.

Gitleaks 는 git 저장소, 파일, 그리고 stdin 을 통해 입력할 수 있는 모든 것에서 비밀번호, API 키, 토큰과 같은 비밀 정보를 탐지하는 도구입니다. 탐지 엔진의 작동 원리에 대해 더 알고 싶다면 이 블로그를 확인하세요: Regex is (almost) all you need.

○
│╲
...

Gitleaks 는 Homebrew, Docker, 또는 Go 를 사용하여 설치할 수 있습니다. Gitleaks 는 releases 페이지에서 많은 인기 있는 플랫폼 및 OS 타입의 바이너리 형태로도 제공됩니다. 또한 Gitleaks 는 Gitleaks-Action 을 사용하여 직접 저장소에 pre-commit hook 로 구현하거나 GitHub action 으로 사용할 수도 있습니다.

brew install gitleaks
# Docker (DockerHub)
...

공식 Gitleaks GitHub Action 을 확인하세요.

on: [pull_request, push, workflow_dispatch]
jobs:
...
  • Install pre-commit from https://pre-commit.com/#install

  • Create a .pre-commit-config.yaml file at the root of your repository with the following content:repos: - repo: https://github.com/gitleaks/gitleaks rev: v8.24.2 hooks: - id: gitleaks

for a native execution of gitleaks or use the gitleaks-docker pre-commit ID for executing gitleaks using the official Docker images

  • Auto-update the config to the latest repos' versions by executing pre-commit autoupdate

  • Install with pre-commit install

  • Now you're all set!

Detect hardcoded secrets.................................................Failed

Note: to disable the gitleaks pre-commit hook you can prepend SKIP=gitleaks to the commit command and it will skip running gitleaks

Detect hardcoded secrets................................................Skipped
Usage:
gitleaks [command]
...

detect and protect. Those commands are still available but are hidden in the --help menu. Take a look at this gist for easy command translations.
If you find v8.19.0 broke an existing command (detect/protect), please open an issue.

There are three scanning modes: git, dir, and stdin.

The git command lets you scan local git repos. Under the hood, gitleaks uses the git log -p command to scan patches.
You can configure the behavior of git log -p with the log-opts option.
For example, if you wanted to run gitleaks on a range of commits you could use the following command: gitleaks git -v --log-opts="--all commitA..commitB" path_to_repo. See the git log documentation for more information.
If there is no target specified as a positional argument, then gitleaks will attempt to scan the current working directory as a git repo.

The dir (aliases include files, directory) command lets you scan directories and files. Example: gitleaks dir -v path_to_directory_or_file.
If there is no target specified as a positional argument, then gitleaks will scan the current working directory.

You can also stream data to gitleaks with the stdin command. Example: cat some_file | gitleaks -v stdin

When scanning large repositories or repositories with a long history, it can be convenient to use a baseline. When using a baseline,
gitleaks will ignore any old findings that are present in the baseline. A baseline can be any gitleaks report. To create a gitleaks report, run gitleaks with the --report-path parameter.

Gitleaks Baseline 활용

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

Once as baseline is created it can be applied when running the detect command again:

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

After running the detect command with the --baseline-path parameter, report output (findings.json) will only contain new issues.

You can run Gitleaks as a pre-commit hook by copying the example pre-commit.py script into your .git/hooks/ directory.

The order of precedence is:

  1. --config/-c option:gitleaks git --config /home/dev/customgitleaks.toml .
  2. Environment variable GITLEAKS_CONFIG with the file path:export GITLEAKS_CONFIG="/home/dev/customgitleaks.toml" gitleaks git .
  3. Environment variable GITLEAKS_CONFIG_TOML with the file content:export GITLEAKS_CONFIG_TOML=cat customgitleaks.toml gitleaks git .
  4. A .gitleaks.toml file within the target path:gitleaks git .

If none of the four options are used, then gitleaks will use the default config.

Gitleaks offers a configuration format you can follow to write your own secret detection rules:

# Title for the gitleaks configuration file.
title = "Custom Gitleaks configuration"
# You have basically two options for your custom configuration:
...

Refer to the default gitleaks config for examples or follow the contributing guidelines if you would like to contribute to the default configuration. Additionally, you can check out this gitleaks blog post which covers advanced configuration setups.

In v8.28.0 Gitleaks introduced composite rules, which are made up of a single "primary" rule and one or more auxiliary or required rules. To create a composite rule, add a [[rules.required]] table to the primary rule specifying an id and optionally withinLines and/or withinColumns proximity constraints. A fragment is a chunk of content that Gitleaks processes at once (typically a file, part of a file, or git diff), and proximity matching instructs the primary rule to only report a finding if the auxiliary required rules also find matches within the specified area of the fragment.

Proximity matching: Using the withinLines and withinColumns fields instructs the primary rule to only report a finding if the auxiliary required rules also find matches within the specified proximity. You can set:

  • required findings must be within N lines (vertically)withinLines: N
  • required findings must be within N characters (horizontally)withinColumns: N

Both- creates a rectangular search area (both constraints must be satisfied)
Neither- fragment-level matching (required findings can be anywhere in the same fragment)

Here are diagrams illustrating each proximity behavior:

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

Some final quick thoughts on composite rules.

이 기능은 실험적 기능입니다! 따라서 이 기능을 기반으로 새로운 B2B SaaS 기능을 개발하여 판매하지 마십시오. 스캔 타입 (git vs dir) 기반 컨텍스트는 흥미롭습니다. 상황을 모니터링 중입니다. 복합 규칙은 gitleaks 가 git 역사에서 추가 사항만 확인하기 때문에 git 스캔에 대해 매우 유용할 수 없습니다. required 규칙을 위해 git 역사에서 추가 사항을 스캔하는 것이 유용할 수 있습니다. 오, 맞습니다 이 README 입니다, 이제 입을 닫겠습니다.

의도적으로 테스트 비밀을 제출하여 gitleaks 가 감지할 경우 해당 줄에 gitleaks:allow

코멘트를 추가하여 gitleaks 를 해당 비밀을 무시하도록 지시할 수 있습니다. 예:

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

특정 발견을 무시하려면 .gitleaksignore 파일을 리포지토리의 루트에 생성할 수 있습니다. Gitleaks v8.10.0 릴리스에서는 Gitleaks 보고서에 Fingerprint 값을 추가했습니다. 각 누출 또는 발견은 비밀을 고유하게 식별하는 Fingerprint 를 가집니다. 해당 특정 비밀을 무시하려면 .gitleaksignore 파일에 이 지문을 추가하십시오. 예는 Gitleaks 의 .gitleaksignore 를 참조하십시오. 참고: 이 기능은 실험적이며 향후 변경될 수 있습니다.

때로는 secrets 는 단순히 regex 로만 찾기 어려운 방식으로 인코딩되어 있습니다. 이제 gitleaks 에 인코딩된 텍스트를 자동으로 찾아解码하도록 지시할 수 있습니다. --max-decode-depth 플래그는 이 기능을 활성화합니다 (기본값 "0" 은 기본적으로 비활성화됨).

인코딩된 텍스트에도 인코딩된 텍스트가 포함될 수 있으므로 디코딩은 재귀적으로 지원됩니다. --max-decode-depth 플래그는 재귀 제한을 설정합니다. 재귀는 인코딩된 텍스트를 더 디코딩할 새로운 섹먼트가 없을 때 중지되므로, 매우 높은 최대 깊이를 설정한다고 해서 그렇게 많은 패스를 실행한다는 뜻은 아닙니다. 필요한 만큼만 실행합니다. 전체적으로 디코딩은 스캔 시간을 최소한으로 증가시킵니다.

인코딩된 텍스트의 발견은 다음과 같이 일반적인 발견과 다릅니다:

  • 위치는 인코딩된 텍스트의 범위를 가리킵니다
  • 규칙이 인코딩된 텍스트 바깥에서 매칭되면 범위는 해당 부분도 포함하도록 조정됩니다
  • 매치 및 비밀에는 디코딩된 값이 포함되어 있습니다
  • 두 개의 태그가 추가됩니다:
    decoded:<encoding>

decode-depth:<depth>

현재 지원되는 인코딩:
percent- 모든 인쇄 가능한 ASCII percent 인코딩 값
hex- 모든 인쇄 가능한 ASCII hex 인코딩 값 >= 32 자
base64- 모든 인쇄 가능한 ASCII base64 인코딩 값 >= 16 자

때로는 secrets 는 zip 파일이나 tarballs 같은 아카이브 파일에 포장되어 발견하기 어려울 수 있습니다. 이제 gitleaks 에 자동으로 추출하고 아카이브의 내용을 스캔하도록 지시할 수 있습니다. --max-archive-depth 플래그는 dirgit 스캔 타입 모두에서 이 기능을 활성화합니다. 기본값 "0" 은 기본적으로 비활성화됨.

아카이브에는 다른 아카이브를 포함할 수 있으므로 재귀 스캔이 지원됩니다. --max-archive-depth 플래그는 재귀 제한을 설정합니다. 재귀는 더 추출할 아카이브가 없을 때 중지되므로, 매우 높은 최대 깊이를 설정한다고 해서 그렇게 깊게 갈 수 있다는 뜻은 아닙니다. 필요한 만큼만 깊이로 갑니다.

아카이브 내의 비밀에 대한 발견은 아카이브 내부 파일의 경로를 포함합니다. 내부 경로는 ! 로 구분됩니다.

예시 발견 (간략화됨):

Finding: DB_PASSWORD=8ae31cacf141669ddfb5da
...
File: testdata/archives/nested.tar.gz!archives/files.tar!files/.env.prod
...

이것은 files/.env.prod. 파일의 4 번째 줄에 감지된 비밀입니다.

이는
archives/files.tar
안에 있으며,

testdata/archives/nested.tar.gz
안에 있습니다.

현재 지원되는 형식:

mholt 의 archives 패키지가 지원하는 압축 및 아카이브 형식이 지원됩니다.

Gitleaks 는 여러 리포트 형식에 대한 내장 지원을 제공합니다: json, csv, junit, 그리고 sarif.

이러한 형식 중 하나가 필요에 맞지 않는다면, Go 의 text/template 파일과 --report-template 플래그를 사용하여 사용자 정의 리포트 형식을 만들 수 있습니다. 템플릿은 Masterminds/sprig 템플릿 라이브러리에서 확장된 기능을 사용할 수 있습니다.

예를 들어, 다음 템플릿은 사용자 정의 JSON 출력을 제공합니다:

# jsonextra.tmpl
[{{ $lastFinding := (sub (len . ) 1) }}
{{- range $i, $finding := . }}{{with $finding}}
...

사용법:

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

--exit-code 플래그를 사용하여 유출이 발생했을 때 항상 종료 코드를 설정할 수 있습니다. 기본 종료 코드:

0 - 유출 없음
1 - 유출 또는 오류 발생
126 - 알 수 없는 플래그

AI 자동 생성 콘텐츠

본 콘텐츠는 GitHub Trending Go (weekly)의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.

원문 바로가기
2

댓글

0