gitleaks/gitleaks-action

Scan commits and pull requests for hardcoded secrets with Gitleaks.

What it does

gitleaks/gitleaks-action runs Gitleaks against the commits in a push or pull request and fails the job when it detects hardcoded secrets such as API keys, tokens, or private keys.

The action declares no with: inputs; it is configured entirely through environment variables (GITHUB_TOKEN, plus optional Gitleaks settings like a custom config).

Usage

on: [push, pull_request]
permissions:
  contents: read
jobs:
  gitleaks:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0   # scan full history, not just the last commit
      - uses: gitleaks/gitleaks-action@v3
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Notes

Check out with fetch-depth: 0; a shallow checkout limits the scan to the fetched commits.

A custom detection config can be supplied via a .gitleaks.toml in the repo or the environment variables documented in the gitleaks-action README.

Licensing for repos owned by organizations has historically required a GITLEAKS_LICENSE key (free for individual accounts); check the current README for the terms that apply to your account type.

Common errors

• A missing GITHUB_TOKEN env var fails the run early: the action needs the token to read PR commits and post results.
• The step exiting non-zero with a findings table is the intended behavior when leaks are detected, not an infrastructure failure. Rotate the secret, then remove it from history or add a documented .gitleaks.toml allowlist entry for a confirmed false positive.

Security and pinning

• A detected secret in git history is compromised even after the file is fixed. Rotate it first; cleaning history is secondary.
• Pin the action to a commit SHA and keep GITHUB_TOKEN at contents: read, the scan needs no write access.

Alternatives and related

Frequently asked questions