Skip to content

feat: secrets detection — pre-commit scan #23

@ms280690

Description

@ms280690

Context

Stage: Pre-commit
Tool: gitleaks
Parent: #4

Why gitleaks

At pre-commit time the goal is to stop secrets before they ever leave the developer's machine — zero CI cost, instant feedback:

  • Pattern-based regex scanning against 150+ built-in secret types (AWS keys, GitHub tokens, private keys, connection strings, etc.)
  • Native pre-commit framework hook — integrates into any repo's existing .pre-commit-config.yaml with one entry
  • Scans staged files and git history on the branch — catches both new secrets and accidentally re-staged historical ones
  • .gitleaks.toml in the consuming repo allows custom rules and path allowlisting for known false positives
  • Hard-blocks the commit on any match — no secret reaches the remote

Pre-commit local hook

Add to the consuming repo's .pre-commit-config.yaml:

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

Reusable workflow — secrets-precommit.yml

CI enforcement: runs gitleaks on every PR so contributors without the local hook are still gated. Scans the full diff of the PR branch.

name: Secrets Pre-commit
on:
  workflow_call:
    inputs:
      fail-on-finding:
        description: 'Hard-fail the workflow on any secret finding'
        default: true
        type: boolean
      config-path:
        description: 'Path to .gitleaks.toml config in consuming repo (optional)'
        default: '.gitleaks.toml'
        type: string

Consuming repo usage

# .github/workflows/secrets.yml
name: Secrets Detection
on: [pull_request]
jobs:
  gitleaks:
    uses: sparkgeo/github-actions/.github/workflows/secrets-precommit.yml@main

Allowlisting false positives

Add a .gitleaks.toml to the consuming repo root for repo-specific rules:

[allowlist]
  description = "Allowlisted patterns"
  paths = [
    '''tests/fixtures/''',
    '''docs/examples/'''
  ]
  regexes = [
    '''EXAMPLE_KEY_[A-Z0-9]{20}'''  # synthetic example keys in docs
  ]

All allowlist entries must include a comment explaining why the finding is a false positive.

Metadata

Metadata

Assignees

Labels

No fields configured for Feature.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions