In March 2022, a Toyota subcontractor accidentally published a piece of source code to a public GitHub repository. Buried inside was a hardcoded access key that granted access to customer email addresses and management numbers for roughly 296,000 people. The key sat exposed for nearly five years before anyone noticed. This is not a rare misstep — it's the default failure mode of modern software development. GitGuardian's 2024 State of Secrets Sprawl report found over 12.7 million hardcoded secrets exposed on public GitHub in 2023 alone, a 28% increase over the prior year, and internal repositories are not meaningfully cleaner. API keys, database passwords, cloud credentials, and signing tokens get typed into code because it's fast, and then they outlive the sprint, the reviewer, and often the employee who wrote them. Here's what's actually driving the problem, and how to find and fix it before it becomes your incident report.
Why Do Developers Hardcode Secrets in the First Place?
Developers hardcode secrets because it is the fastest path to making code run, not because they don't know better. A local .env file feels like overhead when you're debugging a broken integration at 11 PM, so the API key goes straight into config.py "just for now." In a 2023 survey by GitGuardian and the Ponemon Institute, 75% of developers admitted to knowingly committing secrets to code at least once, and 46% said they'd done it more than once. The pattern is structural: CI/CD pipelines need credentials to deploy, test suites need database connections, and secrets managers like Vault or AWS Secrets Manager require setup time that a sprint deadline doesn't budget for. Startups and fast-moving teams feel this most acutely — provisioning a secrets vault feels like premature optimization until the day a scanner (or an attacker) proves otherwise. The result is that "temporary" hardcoded credentials become permanent the moment they're merged, because nobody schedules a follow-up ticket to remove them.
How Do Hardcoded Secrets Actually Get Exploited?
Hardcoded secrets get exploited primarily through public repository scraping, not sophisticated targeted attacks. Attackers run automated bots — some scanning GitHub's public event firehose in near real time — that grep every new commit for patterns matching AWS access keys (AKIA[0-9A-Z]{16}), Slack tokens, Stripe keys, and private key headers. Uber's 2022 breach traced back partly to an attacker finding hardcoded credentials for a PAM (privileged access management) solution on a network share, which they then used to pivot into internal tools including AWS console access. In 2019, Samsung exposed hardcoded API keys and internal source code through a misconfigured GitLab instance, giving researchers direct visibility into how much reach a single leaked credential can have across cloud infrastructure, push notification services, and internal tooling. The exploitation window is often measured in minutes: GitGuardian has documented secrets being scraped and tested by bots within five minutes of a public commit. Even secrets pushed and deleted in a follow-up commit remain retrievable from git history indefinitely unless the repository is rewritten or the credential is rotated — deleting the line of code does not delete the exposure.
Which Types of Secrets Are Most Commonly Hardcoded?
Generic API keys and cloud provider credentials top the list, followed closely by database connection strings and private keys. GitGuardian's telemetry across billions of commits consistently ranks Google API keys, AWS IAM keys, and generic high-entropy tokens as the most frequently detected secret types, with database URIs (especially MongoDB and PostgreSQL connection strings containing plaintext passwords) close behind. RSA private keys and SSH keys are less frequent but disproportionately dangerous, since a single leaked private key can unlock signing authority or persistent server access rather than a single API scope. Slack webhooks and Stripe/payment API keys are also heavily represented, largely because they're used in quick internal scripts and demo integrations that never get moved to a secrets manager. Notably, the mix skews toward "convenience" services — the ones a developer integrates in an afternoon — rather than core infrastructure credentials, which teams tend to already treat with more caution.
Why Doesn't Code Review Catch This Before It Ships?
Manual code review misses hardcoded secrets because reviewers are optimizing for logic and architecture, not scanning every string literal for entropy. A pull request touching 40 files with a 30-character alphanumeric string buried in a config block does not visually stand out from a legitimate hash, UUID, or test fixture — human pattern recognition simply isn't tuned for that discrimination task under time pressure. Compounding this, secrets frequently enter codebases through paths review doesn't cover at all: Jupyter notebooks committed with cached output, Docker images with credentials baked into layers, Terraform state files, and CI configuration YAML that gets treated as "infrastructure" rather than "code" and reviewed less rigorously. A 2023 analysis by Truffle Security found that even security-conscious open-source projects — the kind with mandatory review — still leaked verified, still-active secrets at meaningful rates, because reviewers approved the functional change without independently verifying every credential-shaped string. Review catches what humans are good at: intent, correctness, design. It structurally cannot catch what requires exhaustive pattern-matching across every commit, branch, and historical revision.
How Should Teams Actually Remediate a Hardcoded Secret Once Found?
Rotating the credential comes before removing it from code, because deleting the line without invalidating the secret leaves the exposure live in git history. The correct remediation order is: first revoke or rotate the credential at its source (the cloud provider, the API vendor, the database), second confirm the old credential is fully invalidated, and only third clean up the code — moving the value into an environment variable, a secrets manager, or a vault reference, and scrubbing it from git history with tools like git filter-repo or BFG Repo-Cleaner if the repository is or was ever public. Skipping straight to a code fix is the single most common remediation mistake, because it gives a false sense of resolution while the actual credential remains valid and discoverable in the commit history, forks, and any CI logs that echoed it. Teams should also treat every hardcoded-secret finding as a potential compromise-in-progress until proven otherwise: check access logs for the credential's usage window between exposure and rotation, not just after detection. Organizations with mature programs bake this into an SLA — for example, treating any secret detected in a public repository as requiring rotation within 1 hour, and any in a private repository within 24 hours.
How Common Is This Problem, Really, Across the Industry?
Hardcoded secrets are effectively a universal finding, not an edge case limited to careless teams. GitGuardian's 2024 report found that 1 in every 10 authors who committed to public GitHub in 2023 leaked at least one secret, and that number has held roughly steady or grown for five consecutive years despite widespread awareness campaigns. Verizon's 2023 Data Breach Investigations Report lists credential exposure — including hardcoded and leaked secrets — as a factor in a substantial share of breaches involving external actors. This isn't limited to small or immature engineering shops: Fortune 500 companies, well-funded startups, and government contractors all appear regularly in public secret-leak disclosures, because the root cause (developer velocity outpacing secrets hygiene tooling) scales with organization size rather than shrinking with maturity. The practical takeaway is that "we have good developers" is not a control — detection tooling is, because the failure mode is behavioral and repeats regardless of team skill.
How Safeguard Helps
Safeguard treats hardcoded secret detection as a continuous, pipeline-native control rather than a periodic audit. Our scanning engine inspects source code, commit history, container images, IaC templates, and CI/CD configuration for credential patterns and entropy anomalies, flagging exposures before they merge to a protected branch and continuously across existing repositories to catch what predates adoption. Findings are enriched with context — whether the secret is still active, what scope it grants, and where else it appears across your software supply chain — so teams aren't triaging blind. Safeguard integrates directly into pull request checks and CI gates, so a detected secret can block a merge automatically rather than depending on a reviewer noticing a 40-character string in file 23 of 40. For teams building toward SOC 2 or similar compliance requirements, Safeguard's findings map to audit-ready evidence, turning secret detection from a reactive scramble into a documented, continuous control. If you want to know what's already sitting exposed in your repositories, that's exactly the gap Safeguard is built to close.