Your team runs Gitleaks. You've got pre-commit hooks. You scan every PR. So you're protected from credential leaks, right?
Not exactly. The arrival of Betterleaks, a next-generation fork of Gitleaks developed by Zach Rice with backing from Aikido Security, reveals how much the standard playbook for secrets detection has been missing. More importantly, it exposes the myths that let credentials slip through even when you think you're scanning everything.
These myths persist because secrets detection feels solved. You installed a tool three years ago, it catches AWS keys in commits, and nobody's complained. But the threat model has changed. AI-generated code introduces patterns your ruleset doesn't recognize. Developers copy-paste from Stack Overflow threads that embed test credentials. Your monorepo contains 47 microservices, each with different secret formats.
Here's what your current approach is probably getting wrong.
Myth 1: Entropy-Based Detection Catches Most Secrets
Reality: Entropy analysis alone achieves 70.4% recall on the CredData dataset. Betterleaks hits 98.6% using rule-defined validation with Common Expression Language (CEL).
That 28-percentage-point gap represents the credentials you're not finding. Entropy detection flags random-looking strings, which is great for catching AKIAIOSFODNN7EXAMPLE, but it misses structured secrets that don't look random. Database connection strings follow predictable patterns. JWT tokens have clear structure. OAuth tokens often contain readable metadata.
CEL-based validation lets you write rules that understand context: "This looks like a Stripe key AND it appears in a config file AND it's not in our known test key list." Entropy scanning just sees a moderately random string and shrugs.
Myth 2: Pre-Commit Hooks Prevent All Leaks
Reality: Pre-commit hooks only catch secrets you're about to commit. They don't find credentials already in your history, in dependencies, or in CI/CD pipeline logs.
Consider what happens when a developer bypasses the hook with git commit --no-verify to fix a production incident at 2 AM. Or when your team imports a vendor SDK that hardcodes an API key in example code. Or when your build logs echo environment variables that contain database passwords.
Pre-commit scanning is necessary but insufficient. You need repository-wide scans that check:
- Every branch, including abandoned feature branches from 2019
- Submodules and vendored dependencies
- CI/CD configuration files (
.github/workflows,.gitlab-ci.yml) - Container image layers
- Infrastructure-as-code templates
ISO 27001 Control 8.3 requires you to protect information in storage and transit. "Storage" includes your Git history, all of it, not just the commits that went through your hook.
Myth 3: Fixing Secrets Means Deleting the Commit
Reality: Deleting a commit from your main branch doesn't revoke the credential. The secret is already compromised the moment it hit a remote repository.
Your incident response checklist should start with "rotate the credential," not "rewrite Git history." Even if you force-push to remove the commit, GitHub caches refs for at least 90 days. Anyone who pulled the branch still has the secret in their local history. Search engines may have indexed the commit page.
PCI DSS Requirement 12.10.1 requires an incident response plan that includes containment procedures. For secrets exposure, containment means:
- Rotate the compromised credential immediately
- Audit access logs to identify unauthorized use
- Then clean up the repository history
Rewriting history without rotating credentials is security theater.
Myth 4: AI-Assisted Scanning Is Just Marketing Hype
Reality: LLM-assisted analysis can reduce false positives by understanding code context that regex patterns can't parse.
Traditional scanners flag every string that matches postgres://.*:.*@.*:5432. Your codebase contains 200 matches. Thirty are real credentials. The rest are example URLs in documentation, test fixtures, or commented-out code.
An LLM can read the surrounding context: "This appears in a README under 'Example Configuration.' The username is 'user' and the password is 'pass.' This is likely a placeholder, not a real secret." You still need human review, but you're reviewing 30 candidates instead of 200.
The risk is over-reliance. LLMs hallucinate. They might classify a real credential as a test value because it's in a file called test-config.yml. Use AI to prioritize your review queue, not to auto-dismiss findings.
Myth 5: Open-Source Tools Lack Enterprise Support
Reality: Betterleaks is maintained by contributors from Royal Bank of Canada, Red Hat, and Amazon, organizations with enterprise-grade security requirements.
The "open source means no accountability" argument collapses when your scanner is maintained by engineers at institutions that process millions of transactions daily. These contributors need the tool to work at scale because their employers depend on it.
Open-source governance does create challenges. When Gitleaks development slowed, the community forked to Betterleaks rather than waiting for upstream changes. But this proves the model's resilience, not its fragility. You're not locked into a vendor roadmap that deprioritizes features you need.
For SOC 2 compliance, you'll need to document your tool selection rationale and change management process. "We chose Betterleaks because it's maintained by security teams at RBC, Red Hat, and Amazon, and we review release notes before upgrading" is a defensible position.
What to Do Instead
Start with a baseline scan of your entire repository history, not just recent commits. You're looking for credentials that leaked before you implemented scanning.
Define validation rules that match your actual secret formats. If you use HashiCorp Vault, write a rule that recognizes Vault token structure. If your API keys follow an internal format (like mycompany_live_ followed by 32 hex characters), encode that pattern.
Integrate scanning at multiple points: pre-commit hooks, PR checks, nightly full-repository scans, and container image builds. Each layer catches what the previous one missed.
Build a rotation runbook before you need it. When a scan finds a production database credential in a commit from six months ago, you need to rotate it in minutes, not hours. Document which team owns each credential type and how to revoke it.
And when you evaluate new scanning tools, test them against your actual codebase. The CredData benchmark shows what's possible, but your repository contains secret formats that no benchmark includes. Run the scanner, review the findings, and measure how many are actionable versus noise.
The tool you installed three years ago was good enough for the threats you faced then. The question is whether it's good enough for the code your team ships now.
