Secret Scanning Myths That Put Your Code at Risk

You're running a secret scanner. You've got pre-commit hooks. Your CI pipeline blocks obvious API keys. So you're covered, right?

Not quite. Teams often discover production credentials in public repos weeks after their scanners gave the all-clear. The problem isn't the tools themselves, it's the assumptions about how they work and what they catch.

These myths persist because secret scanning feels like a solved problem. Install Gitleaks, add a GitHub Action, done. But the reality is messier, especially with AI coding assistants generating thousands of lines per developer per week. Let's break down what actually works.

Myth 1: Pre-commit Hooks Stop All Credential Leaks

The Reality: Pre-commit hooks only protect when developers remember to use them.

Your team clones a repo on a new machine. They forget to run the setup script that installs hooks. Or they use git commit --no-verify because they're in a hurry. Or they're working in a Jupyter notebook that commits directly through the web interface.

I've seen this play out: a developer copies a database connection string into a config file, commits through VS Code's GUI (bypassing the hook), and pushes to a feature branch. The secret sits there for three days before anyone notices.

Pre-commit hooks are useful, but they're not a perimeter. You need server-side scanning that catches everything that hits your repository, regardless of how it got there. That's why tools like Betterleaks run in CI/CD pipelines, they're the last line of defense before code becomes permanent history.

Myth 2: Secret Scanners Find All Secrets

The Reality: Default rulesets catch obvious patterns, not context-aware secrets.

Most scanners look for high-entropy strings and known patterns: AWS access keys, GitHub tokens, RSA private key headers. They're great at finding AKIAIOSFODNN7EXAMPLE but terrible at finding db_password = "correcthorsebatterystaple" in a production config file.

Here's what gets missed:

• API keys that don't follow standard formats
• Passwords stored as plain strings without obvious variable names
• Service account credentials in JSON files
• SSH keys without the standard header format
• Tokens split across multiple lines or obfuscated

Betterleaks addresses this with Common Expression Language (CEL) for validation checks. Instead of just pattern matching, you can write rules that understand context: "If this looks like a password AND it's in a production config file AND it's not a placeholder value, flag it."

You still need manual review. When your scanner flags 200 findings in a legacy codebase, someone has to determine which are real credentials and which are example strings from documentation.

Myth 3: AI-Generated Code Is Safer Because It Doesn't Have Access to Real Secrets

The Reality: AI assistants inherit whatever's in your codebase and your clipboard.

Your developer asks Copilot to write a database connection function. Copilot looks at similar functions in your repo, including the one from two years ago that hardcoded credentials. It suggests code that follows the same pattern.

Or consider this scenario: you're testing an API integration. You copy your production API key to test a curl command. Five minutes later, you ask your AI assistant to write a Python script for the same endpoint. It helpfully includes the key that's still in your clipboard context.

AI tools don't introduce new types of secrets, but they accelerate the velocity at which code gets written and committed. A developer who used to write 50 lines per day now writes 500. That's 10x more opportunities for a credential to slip through, and 10x less time spent reviewing each line.

The solution isn't to ban AI tools, it's to scan faster and more frequently. If your secret scanner runs once per day, you're giving credentials a 24-hour window to leak. Run it on every push.

Myth 4: Once You've Scanned a Repo, You're Done

The Reality: Repository history is immutable, and secrets live forever in git history.

You find an AWS key in your main branch, remove it, and commit the fix. Problem solved?

No. That key is still in your git history. Anyone who clones the repo can run git log -p and find it. Automated scrapers do exactly this, they clone repos, scan the entire history, and harvest credentials.

When you find a secret in a repository:

1. Revoke the credential immediately
2. Remove it from current code
3. Rewrite git history to purge it completely (using git filter-branch or BFG Repo-Cleaner)
4. Force-push the cleaned history
5. Verify that all team members re-clone

This is painful. It breaks everyone's local branches. But it's the only way to actually remove a secret from a repository.

Better approach: catch it before it enters history. That's why Betterleaks maintains compatibility with Gitleaks configurations, teams can upgrade to faster scanning without rewriting their entire detection ruleset.

Myth 5: Secret Scanning Is a Security Team Problem

The Reality: Developers create secrets, developers commit them, developers need to fix them.

I've worked with teams where security runs a weekly scan and emails developers a list of findings. Response time: 3-7 days. By then, the credentials have been exposed for a week.

Effective secret management requires:

• Developers running local scans before pushing
• CI pipeline blocks that fail builds with exposed secrets
• Clear ownership: the person who committed the secret revokes and rotates it
• Automated alerts to both the developer and security team

When Aikido sponsored Betterleaks as an open-source tool, they recognized this reality: secret scanning needs to be embedded in developer workflows, not bolted on as an afterthought.

Your developers aren't trying to leak credentials. They're moving fast, juggling multiple contexts, and working with tools that encourage copy-paste. Make it easier to do the right thing than the wrong thing.

What to Do Instead

Stop treating secret scanning as a checkbox. Build a system:

Scan everywhere: Pre-commit hooks, CI/CD pipelines, periodic full-repo scans, and real-time monitoring of public repositories.

Validate findings: Use tools that support custom validation rules (like Betterleaks' CEL support) to reduce false positives and catch context-specific secrets.

Automate response: When a secret is detected, automatically create a ticket, notify the developer, and block the deployment. Don't rely on someone checking email.

Rotate by default: Treat any credential that touches a developer machine as potentially compromised. Use short-lived tokens, automatic rotation, and secrets management systems (not environment variables in .env files).

Measure what matters: Track mean time to detection, mean time to revocation, and repeat offenders. If the same developer leaks credentials three times, they need training, not another warning email.

The tools are getting better. Betterleaks scans faster, validates smarter, and integrates with modern development workflows. But the tool is only as good as the process around it. Build the process first.

Common Expression Language (CEL)