Hardcoded Secrets in Code: Why They Keep Showing Up

A hardcoded API key or database password is one of the most consistently recurring findings in real code reviews, not a rare, careless slip, and the trend is getting worse, not better. GitGuardian's State of Secrets Sprawl 2026 report found 28.65 million new hardcoded secrets added to public GitHub commits in 2025 alone, a 34% year-over-year increase, and the largest single-year jump the report has recorded. That's public repositories; the same report found internal, private repos have a meaningfully higher secret-exposure rate than public ones, since the (often false) assumption of privacy makes teams less careful there, not more.

Why it keeps happening despite everyone knowing better

Nobody sets out to hardcode a production credential. It happens through a specific, repeatable sequence: a developer hardcodes a key locally "just to get something working," commits it because the change also includes real functional code, and either forgets to remove it before pushing or assumes a later cleanup pass will catch it. CI/CD pipeline configuration files, .env files accidentally un-ignored, and Docker images with credentials baked into a layer are the next most common sources, none of which show up in a normal code review that's focused on logic and functionality, not scanning every line for a plausible-looking secret.

Why git history makes this worse than it looks

Deleting a hardcoded secret in a later commit doesn't remove it, it's still fully recoverable from git history unless the history itself is rewritten, which most teams never do. A secret that was live in a repository for even a single commit should be treated as compromised and rotated, not just removed going forward; this is one of the most common gaps we find even at organizations that otherwise have decent secret-scanning tooling.

Where we find real, exploitable instances

• API keys and database connection strings committed directly in application code
• Cloud provider credentials in Infrastructure-as-Code files (Terraform, CloudFormation) committed alongside legitimate configuration
• OAuth client secrets and signing keys in mobile app builds, which are trivially extractable from the compiled artifact itself
• CI/CD pipeline configuration files with plaintext credentials instead of a secrets manager reference
• Secrets in commit history, still recoverable even after being "removed" in a later commit

The fix

• A real secrets manager (cloud-provider KMS-backed, or a dedicated tool) with runtime injection, not environment variables checked into version control
• Pre-commit and CI-pipeline secret scanning that blocks a push containing a detected credential pattern, not just an after-the-fact report
• Treating any historically-committed secret as compromised on discovery, rotate it, don't just delete the line
• Short-lived, scoped credentials over long-lived static keys wherever the platform supports it

This is exactly what our Secure Code Review engagements are built to catch, a manual review specifically looking for this pattern, not just an automated scanner's best guess at what looks like a secret. For the broader set of configuration gaps this sits alongside, see our piece on common cloud security misconfigurations.