4 MIN READ
Picture the average API key. Long random string, scoped to production, never rotated, sitting in a config file the engineering org wrote two years ago. The credential scraper found it twenty minutes after the file landed in a public repo. The breach shows up in next quarter’s incident report. By then the key has paid for itself, in whatever currency the credential scraper was using.
Lineage worth knowing. GitGuardian’s 2025 report counted 12.8 million secrets detected in public GitHub commits, up 28% on the year before. The State of Secrets Sprawl 2026 update puts the average time to first detection at 27 days for any leak that nobody is looking for, and 12 days for the ones the credential scrapers are actively watching. HashiCorp Vault, AWS Secrets Manager, and Azure Key Vault hold most of the secret management market, and the engineering orgs that pay for them still leak production keys to public repos at roughly the same rate as the ones that do not. The contradiction has a name, and a price tag.
How the key actually leaks
Most leaks amount to the boring kind, not the dramatic kind. The everyday pattern looks like this: an engineer commits a config file with a hardcoded key for the staging environment, the staging key happens to share the same IAM role as production, the file goes public when the repo gets forked or the .gitignore misses a directory, and the credential scraper picks the string up within hours. GitHub’s own secret scanning service caught 1.8 million such patterns in 2025, a small slice of what the platforms see. The bigger slice sits in keys that nobody scans for at all. Front end JavaScript embeds the second largest category, where the API key for the public service gets shipped into the bundle and the user can read it from the browser console. Then there sits the log line category. Application prints the full request including the bearer token for debugging, the log lands in the centralised SIEM, and the SIEM search index becomes the leak vector six months later when the analyst runs the wrong query.
What the cost looks like
Three things determine the price, and they multiply rather than add. The scope of the key runs first, and most keys are not scoped at all: the AWS access key that can read S3 and write to DynamoDB and spin up EC2 instances, the one the engineer issued with administrator access because the project was on a deadline and the IAM policy looked like paperwork. The blast radius amounts to the multiplier that follows, and it depends on what the API key can reach: a read only key to a non sensitive bucket sits as one number, a write capable key to a payment processor sits as a different number by several orders of magnitude. The detection gap closes the calculation, sitting as the multiplier that turns a contained incident into a quiet one: the legitimate cron job calling the same API on the same schedule, the SIEM that has learnt the pattern as trusted, the threat actor that looks exactly like the cron job does at 3am. The 2025 IBM Cost of a Data Breach report puts the average cost of a credential based incident at 4.81 million dollars, and that number has been climbing year on year.
How to actually prevent it
The engineering org that wants to stop the bleeding has three moves to make, and they compound. The secret manager goes in before the first line of code, not after, with HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, or Doppler all working if the integration gets built into the deployment pipeline on day one. The cost amounts to one sprint, while the alternative sits as the cost the postmortem ends up writing. The scope on the key gets cut to the minimum the workload actually needs, with read only where read only sits as enough, scoped to a single resource where the API supports it, time bound where the workload runs as a long running service. The blast radius the credential scraper exploits amounts to the blast radius the IAM policy did not limit. The rotation runs on a schedule the security org can defend, automated through the CI pipeline or the secret manager’s native rotation, and revoked within minutes of any detection event. A key that never gets rotated amounts to a key that keeps working long after the leak.
The bottom line
Secret manager, scope limit, rotation, in that order. Keys that never land in a public repo are the ones nobody scrapes. Keys scoped to a single resource amount to keys that limit the blast radius when the credential scraper finds them. Keys that rotate on a schedule are the ones that stop working the moment the leak gets found. Build the pipeline before the leak, not after.
Sources & Further Reading
All claims in this article are sourced from primary documentation, vendor advisories, and reputable security researchers.
Spotted an error? Email the editor. Corrections are issued with a visible correction note.
Editorial standards. Every article on humanrequired.org is reviewed by a human editor before publication. AI may assist with drafting or research; final editorial control is human. Read the full standards.
