Gitleaks
secret detection in git history. Part of AuditCore's automated security audit pipeline — runs on every scan in the Enterprise tier and above, with findings normalized into a single severity-rated table.
What is Gitleaks?
gitleaks scans git history (not just current files) for secrets that have been committed at any point in the repo's lifetime. This is critical because once a secret hits git, it lives there forever — even if you delete the file in a later commit, the secret remains in history and any clone of the repo (including forks and CI cache copies) still contains it.
AuditCore runs gitleaks in the static phase when a repository URL is provided. We use `gitleaks detect --no-git=false --redact --report-format json` which scans the full commit history. Patterns include: AWS access keys, GCP service account JSON, Stripe API keys, Slack tokens, GitHub PATs, generic high-entropy strings (passwords, JWT signing secrets), private keys (RSA, SSH, PGP), database connection strings.
What gitleaks finds that complementary scanners miss: secrets committed and then deleted (`git log -p` would show them but who looks?). Secrets in branch history that never made it to main. Secrets in dependency lockfiles or generated config that you forgot to add to .gitignore. The gold-standard catch: a developer hardcodes a secret 'just for testing', commits, then 5 minutes later moves it to .env — the original commit still has the secret and it's now in everyone's clone of the repo forever.
Remediation isn't 'delete the line and commit' — it's 'rotate the credential immediately, then optionally rewrite history with `git filter-repo` to erase the secret from the past'. If the repo is public (or has been public at any point), assume the secret is compromised and act accordingly. AuditCore reports each finding with the commit SHA and file path so you can verify and rotate.
What it tests
- AWS access keys (AKIA... patterns + secret key heuristics)
- GCP service account JSON (private_key field)
- Stripe live and test API keys
- GitHub Personal Access Tokens (ghp_...)
- GitLab personal/project tokens
- Slack bot/user tokens (xoxb-, xoxp-)
- Twilio account SIDs and auth tokens
- SendGrid API keys
- Mailgun API keys
- Heroku API keys
- JWT signing secrets (high-entropy strings near JWT-related code)
- Private keys (RSA, EC, SSH, PGP)
- Database connection strings (postgres://, mongodb://, mysql://)
- Generic high-entropy strings (configurable)
Where it runs in the AuditCore pipeline
Phase 5/5 · Static / Code & Mobile
Source-code, dependency and mobile-binary analysis — Semgrep rules, gitleaks secrets, Trivy CVEs, APK / IPA manifest, permissions, strings, network and native-binary hardening.
Source: scanners/gitleaks_scanner.py
Sample findings
AWS access key in .env.example committed 6 months ago
Critical. Even though .env.example is supposed to be a template, this commit included a real AKIA... key. The key is now permanent in git history. Mitigation: rotate the key in AWS IAM immediately. Optionally rewrite history with `git filter-repo --path .env.example --invert-paths` then force-push (coordinate with team — destructive operation).
Stripe live API key in src/payments/config.js (3 months ago)
Critical. A live `sk_live_...` Stripe key was committed and then moved to environment variables in a later commit. The key is in git history. Mitigation: rotate in Stripe dashboard immediately, audit Stripe activity log for unauthorized usage, then optionally `git filter-repo` to remove from history.
Hardcoded JWT signing secret in production config
Critical. A 128-bit JWT signing secret was hardcoded as `JWT_SECRET = 'super-secret-key-12345'`. Once anyone outside your team gets this repo, they can forge JWTs claiming any user identity. Mitigation: generate a new secret with `openssl rand -base64 64`, deploy via env var, invalidate all existing JWTs (force re-login), then rewrite history.
RSA private key in deploy/keys/prod.pem
Critical. A complete `-----BEGIN RSA PRIVATE KEY-----` block in the repo. Likely a deployment SSH key. Mitigation: rotate the key (revoke from authorized_keys on all servers, generate new pair, update CI/CD secrets), then remove from history.
Other static / code & mobile scanners
FAQ
What's the difference between gitleaks and TruffleHog?
Both scan git history for secrets. gitleaks is faster, has cleaner output, and uses regex+entropy patterns. TruffleHog v3+ adds verified detection (it actually tries each found credential against the relevant API to confirm validity, reducing false positives). For AuditCore's automated pipeline, gitleaks is the right balance of speed and coverage. If you want zero false positives via API verification, run TruffleHog against AuditCore's findings to verify.
How far back does gitleaks scan in git history?
All commits reachable from any branch. For a repo with 10,000 commits, expect ~30-60 second scan time. AuditCore caps at 5 minutes — if your repo is genuinely larger, we report partial results. For monorepos, this is usually fine since modern git stores blobs efficiently.
Can gitleaks find secrets in archived repos or deleted branches?
It finds secrets in any commit reachable from current refs. Deleted branches whose commits are still reachable (because they're in another branch's history) are scanned. Truly orphaned commits (deleted branch with no other refs pointing to its commits) require `git fsck --lost-found` to recover and are not scanned.
I have a secret in history but it's already rotated. Should I still rewrite history?
Depends on repo visibility. Public repo: yes, definitely — even with the secret rotated, leaving it visible is professional embarrassment and signals 'this team has loose secret hygiene'. Private repo: less urgent, but rewriting history is good hygiene for compliance audits. Either way, document the rotation in your incident log.
Can I add custom patterns for AuditCore's gitleaks to detect?
Not via self-serve currently. Custom patterns (e.g. internal API key formats) are on the Enterprise roadmap. For now, you can run gitleaks locally with custom rules — `gitleaks detect --config .gitleaks.toml`.