Stop Secrets Leaking to GitHub: Pre-commit Hooks, Push Protection, and What to Do When It Happens Anyway

A pre-commit hook runs locally before the commit is finalized. The developer never sees a rejected push -- the secret is caught before it enters Git history.

Install pre-commit and gitleaks:

# macOS
brew install pre-commit gitleaks

# Linux
pip install pre-commit
# gitleaks: download binary from https://github.com/gitleaks/gitleaks/releases
curl -sSL https://github.com/gitleaks/gitleaks/releases/download/v8.18.4/gitleaks_8.18.4_linux_x64.tar.gz | tar -xz
sudo mv gitleaks /usr/local/bin/

Create .pre-commit-config.yaml in your repo root:

# .pre-commit-config.yaml
repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.18.4
    hooks:
      - id: gitleaks
        name: Detect hardcoded secrets
        description: Detect secrets using gitleaks
        entry: gitleaks protect --verbose --redact --staged
        language: golang
        pass_filenames: false

Install hooks in every developer's local repo:

pre-commit install

Add to your project README and onboarding script:

# setup.sh
pip install pre-commit  # or: brew install pre-commit
pre-commit install
echo "pre-commit hooks installed"

Test it works:

echo 'AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY' > test-secret.txt
git add test-secret.txt
git commit -m 'test'
# Should output: WARN[0000] leaks found: 1
# And block the commit
git restore test-secret.txt
rm test-secret.txt

gitleaks ships with patterns for common secrets (AWS, GCP, Stripe, GitHub, Slack, etc.). For internal secrets -- your own API tokens, internal service credentials -- add a custom rules file.

Create .gitleaks.toml in your repo root:

# .gitleaks.toml
title = "Custom gitleaks config"

[extend]
# Use the default rules as a base
useDefault = true

[[rules]]
id = "internal-api-token"
description = "Internal API token (format: ipt_[32 alphanumeric chars])"
regex = '''ipt_[a-zA-Z0-9]{32}'''
tags = ["internal", "api"]

[[rules]]
id = "internal-db-password"
description = "Database connection string with password"
regex = '''(postgresql|mysql|mongodb)://[^:]+:[^@]{8,}@'''
tags = ["database"]

# Allow specific patterns that are false positives in your codebase
[[allowlists]]
description = "Allowlisted paths"
paths = [
  '''.gitleaks.toml''',  # the config file itself
  '''tests/fixtures/.*''',  # test fixtures with example values
]

[[allowlists]]
description = "Allowlisted patterns (test/example values)"
regexes = [
  '''EXAMPLE_KEY_DO_NOT_USE''',
  '''your-api-key-here''',
]

Update the hook to use this config:

      - id: gitleaks
        entry: gitleaks protect --verbose --redact --staged --config=.gitleaks.toml

Push protection intercepts secrets at the remote. Even if a developer bypasses or hasn't installed the local hook, push protection blocks the push.

Enable organization-wide (preferred):

GitHub Organization > Settings > Code security and analysis
> Secret scanning > Push protection: Enable for all repositories

Enable per-repository:

Repository > Settings > Security > Code security and analysis
> Secret scanning > Push protection: Enable

What happens when a secret is detected:

1. Developer runs git push
2. GitHub blocks the push and shows which file + line contains the secret
3. Developer must either: remove the secret and re-commit, or click through a bypass reason

Monitor bypass events (weekly):

Organization > Security > Secret scanning > Bypassed alerts

Or use the GitHub API:

curl -H "Authorization: Bearer $GH_TOKEN" \
  "https://api.github.com/orgs/YOUR_ORG/secret-scanning/alerts?state=open&resolution=used_in_tests,false_positive,wont_fix" \
  | jq '.[] | {repo: .repository.name, secret_type: .secret_type, bypassed_at: .updated_at, url: .html_url}'

Set up a GitHub Actions workflow to notify your security channel when a bypass occurs:

# .github/workflows/secret-bypass-alert.yml
name: Alert on Secret Scanning Bypass
on:
  schedule:
    - cron: '0 9 * * 1'  # Every Monday 9am UTC
jobs:
  check-bypasses:
    runs-on: ubuntu-latest
    steps:
      - name: Check for bypassed secret alerts
        run: |
          count=$(curl -s -H "Authorization: Bearer ${{ secrets.GH_TOKEN }}" \
            "https://api.github.com/orgs/${{ vars.ORG_NAME }}/secret-scanning/alerts?state=open" \
            | jq 'length')
          echo "Open secret scanning alerts: $count"
          # Integrate with Slack/Teams webhook for notification

The CI scan runs on every PR and catches any secret that made it past the local hook and push protection (e.g., in a repository where hooks weren't installed, or in a file type push protection doesn't scan).

GitHub Actions workflow:

# .github/workflows/secrets-scan.yml
name: Secret Scanning

on:
  pull_request:
  push:
    branches: [main, master]

jobs:
  gitleaks:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0  # Full history required for gitleaks

      - name: Run gitleaks
        uses: gitleaks/gitleaks-action@v2
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        with:
          args: detect --source . --config .gitleaks.toml --verbose

For PRs, scan only the changed commits:

      - name: Run gitleaks on PR changes only
        if: github.event_name == 'pull_request'
        uses: gitleaks/gitleaks-action@v2
        with:
          args: detect --source . --log-opts "${{ github.event.pull_request.base.sha }}..${{ github.event.pull_request.head.sha }}" --verbose

Scan results as PR comments: The gitleaks-action automatically comments on PRs when secrets are found. Developers see the specific file, line, and rule that triggered -- actionable, not just a failed job.

The moment a secret is pushed to a remote repository, assume it has been seen. GitHub repositories are scraped by automated tools within minutes of a push -- even private repositories if the token is exposed.

Minute 0-5: Confirm and contain

# Confirm the secret type (what can it access?)
git log --all -p | grep -A2 -B2 'SECRET_VALUE'

# Check if the commit is public or in a private repo
gh api repos/ORG/REPO --jq '.private'

Minute 5-15: Revoke the credential immediately

Do this BEFORE cleaning history. A revoked credential is harmless even if someone has already copied it.

Minute 15-30: Check for exploitation

# AWS: check CloudTrail for activity since the secret was committed
aws cloudtrail lookup-events \
  --start-time $(date -d '24 hours ago' --iso-8601=seconds) \
  --lookup-attributes AttributeKey=Username,AttributeValue=COMPROMISED_USER \
  | jq '.Events[] | {time: .EventTime, action: .EventName, ip: .CloudTrailEvent | fromjson | .sourceIPAddress}'

# GitHub: check the token's audit log before revocation
gh api /orgs/ORG/audit-log?phrase=actor:USERNAME --jq '.[] | {action, created_at, actor}'

Minute 30-60: Remove from Git history

# BFG Repo Cleaner (faster than git filter-branch)
brew install bfg

# Create a file with the secret value to replace
echo 'ACTUAL_SECRET_VALUE' > secrets-to-remove.txt

# Clone a fresh copy (BFG requires a clean clone)
git clone --mirror https://github.com/ORG/REPO.git
cd REPO.git

# Replace the secret with REMOVED in all history
bfg --replace-text ../secrets-to-remove.txt

# Clean and force push
git reflog expire --expire=now --all
git gc --prune=now --aggressive
git push --force

Minute 60-90: Verify and document

# Confirm secret is gone from all branches
git log --all -p | grep -c 'ACTUAL_SECRET_VALUE'
# Should output: 0

# Verify on GitHub
gh api /repos/ORG/REPO/git/refs --jq '.[] | .ref'
# Check main + all branches

Document in your incident log: what the secret was, when it was committed, when revoked, whether exploitation evidence was found, and what remediation was applied.

When rolling out these controls, send this to engineering leads:

Subject: New secret scanning controls rolling out [DATE]

We're adding automated secret scanning to prevent accidental credential exposure. Here's what's changing and what you need to do:

What's new:

• GitHub push protection is now enabled organization-wide. If you push a file containing an AWS key, API token, or other credential pattern, the push will be blocked with an explanation.
• Pre-commit hooks with gitleaks are now part of project setup. Run: pre-commit install in any repository where you're working.

If you get a false positive: If you're intentionally pushing example/test values and get blocked, you have two options:

1. Add the value to your .gitleaks.toml allowlist (preferred for recurring patterns)
2. Click 'Bypass' in the GitHub UI and select the appropriate reason

All bypasses are reviewed weekly by the security team. If you have a legitimate reason, that's fine -- we just want visibility.

Questions? [security-team Slack channel]

Set these up in your first week and review monthly:

Monthly audit query (list repos without push protection):

gh api /orgs/ORG/repos --paginate \
  | jq '.[] | select(.security_and_analysis.secret_scanning_push_protection.status != "enabled") | .full_name'