gitleaks "leaks found" exit code 1 fails the build in CI

By Kaveh Alemi·Latchkey

gitleaks scanned your commits, matched at least one detection rule, printed "leaks found: N" and exited with code 1. In CI, exit 1 fails the step by design so the secret is not merged.

What this error means

The gitleaks step ends with a WRN line "leaks found: 3" and "Error: Process completed with exit code 1". Each finding lists the rule, file, and commit that matched.

Finding:     aws_secret = "AKIA...redacted..."
RuleID:      aws-access-token
File:        config/settings.py
Commit:      3f2a9c1
9:12AM INF scanned ~412 commits
9:12AM WRN leaks found: 3
Error: Process completed with exit code 1

Common causes

A real secret is present in the scanned history

gitleaks matched a rule such as aws-access-token or generic-api-key against a value in a tracked file or a past commit, so it reports a leak.

A false positive from a broad generic rule

A test fixture, example key, or high-entropy string trips a generic rule even though it is not a live credential.

How to fix it

Triage each finding, then remove or allowlist it

1. Open the file and commit named in each Finding block.
2. If the secret is real, rotate it and purge it from history, then update the code to read it from a secret.
3. If it is a confirmed false positive, add a scoped allowlist entry in .gitleaks.toml rather than disabling the rule globally.

[allowlist]
description = "test fixtures"
paths = ['''tests/fixtures/.*''']
regexes = ['''EXAMPLE_KEY_[A-Z0-9]+''']

Confirm the finding locally before pushing

Run the same scan locally so real leaks are caught before CI. Use --redact so the value is not printed in logs.

gitleaks detect --source . --redact --exit-code 1

Make the gate meaningful

• Fail the build on the severity you actually intend to block, and set it explicitly. A scanner that reports without failing is documentation, not a gate.
• Scan the artifact you ship, not the source tree. A vulnerability in a base image will not appear in a source scan.
• Pin the scanner version and its database snapshot for reproducibility, then update deliberately; a floating database turns an unrelated push into a red build.
• Give the job a way to record accepted risk, or people will disable the gate rather than triage it.

How to prevent it

• Keep a reviewed .gitleaks.toml allowlist for known fixtures.
• Rotate any credential that a scan flags as real, do not just ignore it.
• Run gitleaks in a pre-commit hook so leaks never reach CI.

Frequently asked questions

Related guides

References

• GitHub Actions documentation