GitGuardian Analysis Reveals High Risk of Credential Exposure via Local Machine Secret Stores
TL;DR
- Over 23.8 million secrets were exposed on public GitHub in 2024.
- 70% of secrets leaked in 2022 remain active and valid today.
- Security risks are shifting from code repositories to local developer machines.
- CLI tools and shell history files are becoming primary targets for infostealers.
- AI coding agents are increasing the volume of local sensitive configuration files.
The latest State of Secrets Sprawl 2025 report is out, and the numbers are, frankly, sobering. We’re looking at 23.8 million secrets exposed on public GitHub repositories in 2024 alone. That’s a 25% jump from the year before. Despite all the talk about "shifting left" and better security hygiene, the volume of sensitive data leaking into version control isn't just steady—it’s accelerating.
It’s not just the sheer volume that’s keeping security teams up at night; it’s the shelf life of these mistakes. Data shows that 70% of the secrets leaked back in 2022 are still active and valid today. That’s a massive failure in how we handle credential lifecycles. And don’t think this is just a "public repo" problem. Private repositories are just as messy, with 35% of them harboring at least one plaintext secret.
The landscape is getting weirder, too. Generic secrets—simple passwords and database credentials—now make up 58% of all leaks. Even our collaboration tools are turning into liabilities; 6.1% of Jira tickets are currently sitting on sensitive credentials, essentially turning project management software into a treasure map for attackers.
The Shift Toward Local Machine Vulnerabilities
Most teams have figured out how to scan their repositories. We’ve got the CI/CD guardrails, the pre-commit hooks, and the automated alerts. But here’s the catch: the real danger has migrated from the code itself to the hardware sitting on the developer's desk.
Developer laptops have become high-risk credential vaults. These machines are stuffed with keys, tokens, and session data that traditional scanners—which are busy watching the Git history—never see. It’s a blind spot, and it’s a big one.
Think about how we actually work. Cloud CLI tools for AWS, Azure, and Google Cloud are notorious for dumping static access keys and session tokens onto the disk by default. Then there are the shell history files—.bash_history, .zsh_history, you name it. These files are plaintext goldmines for infostealer malware, and because they aren't tracked in version control, they fly completely under the radar of standard security tooling.
To make matters worse, AI coding agents are now in the mix. These tools are fantastic for productivity, but they also churn out a mountain of local configuration files. Each one is a potential hiding spot for an environment variable or a hardcoded token. As we lean harder into AI-assisted coding, the number of files that need oversight is exploding, and the window for unauthorized access is widening.
The Reality of the Risk
The gap between how we treat public versus private repositories is glaring. We tend to throw the kitchen sink at public code, but private environments? They’re often treated like the "safe zone," which is exactly why they aren't. AWS IAM keys, for example, show up five times more often in private repos than in public ones. It seems that when developers think no one is watching, they get a little too comfortable.
| Metric | Observation |
|---|---|
| Public GitHub Leaks (2024) | 23.8 Million |
| Year-over-Year Increase | 25% |
| Private Repo Vulnerability | 35% contain plaintext secrets |
| Leak Persistence | 70% of 2022 secrets remain active |
| Jira Ticket Exposure | 6.1% of tickets contain secrets |
Addressing the Credential Lifecycle Crisis
We need to stop pretending that scanning the repo is enough. If we’re going to get a handle on this, we have to start looking at endpoint hygiene. It’s not just about the code; it’s about the machine.
Here’s where the focus needs to shift:
- Endpoint Awareness: Security teams need to get comfortable looking at
~/.aws, local config files, and shell histories. If it’s not in Git, it’s not being scanned—and that’s exactly where the attackers are looking. - Automated Remediation: Since 70% of old leaks are still valid, we have a massive revocation problem. We need workflows that don't just find the secret—they kill it the moment it’s detected.
- Developer Training: 15% of commit authors leaked a secret in 2024. This isn't a "bad developer" problem; it’s a tooling problem. We need better ways to prevent these secrets from hitting the disk in the first place.
- Tooling Integration: Implementing local guardrails for secrets security is a necessary step to catch these exposures before they ever leave the developer's laptop.
Storing static credentials on a local machine is a fundamental weakness in the modern software development lifecycle. With infostealer malware getting smarter by the day, leaving plaintext keys on a laptop is basically leaving the front door to your cloud infrastructure wide open.
Mitigation isn't a one-size-fits-all fix. It requires a multi-layered strategy. We need to focus on protecting developers' secrets by extending our reach beyond the repository and into the local environment. We also need to foster a good samaritan culture, where developers feel empowered to flag a potential leak without worrying about the repercussions.
The end goal is simple: decouple the developer’s local machine from the long-lived credentials that grant access to production. If we can move toward ephemeral credentials and stop the habit of keeping static keys on workstations, we can shrink the attack surface significantly. The data from GitGuardian makes it clear: the current trajectory is unsustainable. It’s time to change how we handle credentials, both in our code and on our machines.
