Our latest State of Secrets Sprawl report shows that a staggering 70% of secrets exposed in public repositories in 2022 are still valid today. That means attackers don’t just have a window of opportunity—they often have an open door, year after year.
"Finding an exposed credential marks the beginning, not the end, of the security challenge," explains our research team. "The critical gap lies in rapid response and remediation capabilities."
Why Exposed Secrets Remain Valid
The persistence of valid credentials after exposure points to fundamental organizational challenges. Either organizations lack awareness that their credentials have been compromised—a security visibility problem—or they struggle with the resources, processes, or urgency needed for proper remediation—a security operations problem.
In both scenarios, we observe that these secrets aren't being routinely revoked, neither automatically through default expiration nor manually as part of regular rotation procedures.
Organizations often remain unaware of exposed credentials or lack the resources to address them effectively. Hardcoded secrets proliferate across codebases, making comprehensive remediation challenging. Secret rotation requires coordinated updates across services and systems, often with production impact.
Resource constraints force prioritization of only the highest-risk exposures, while legacy systems create technical barriers by not supporting modern approaches like ephemeral credentials.
The Unseen Risk of Git History
One of the reasons secrets persist is the way Git works. Simply removing a secret from a file does not erase it from the project's commit history. Unless you actively rewrite history using tools like git filter-branch or BFG Repo-Cleaner, the secret remains accessible in older commits. Attackers regularly exploit this, searching entire histories for credentials that have been "deleted" but are still present.
Guest Expert
This combination of limited visibility, operational complexity, and technical limitations explains why hardcoded secrets often remain valid long after exposure. Moving to modern secrets security solutions with centralized, automated systems and short-lived credentials is now an operational necessity, not just a security best practice.
Which Services Are Most At Risk? The Trends
Behind the raw statistics lies an alarming reality: critical production systems remain vulnerable due to exposed credentials that persist for years in public repositories. Our analysis of exposed secrets from 2022-2024 reveals that database credentials, cloud keys, and API tokens for essential services continue to remain valid long after their initial exposure. These are not test or development credentials but authentic keys to production environments, representing direct pathways for attackers to access sensitive customer data, infrastructure, and business-critical systems.
Sensitive Services Still Exposed (2022–2024)
MongoDB credentials allow attackers to exfiltrate or corrupt data. These are highly sensitive, offering potential attackers access to personally identifiable information or technical insight that can be used for privilege escalation or lateral movement.
Google Cloud keys, AWS credentials, and Tencent Cloud tokens grant potential attackers access to infrastructure, code, and customer data.
MySQL and PostgreSQL database credentials persist in public code each year as well.These are not test credentials, but keys to live services.
Over the past three years, the landscape of exposed secrets in public repositories has shifted in ways that reveal both progress and new risks, especially for cloud and database credentials. Once again, these trends reflect only the ones that have been found and are still valid—meaning they have not been remediated or revoked despite being publicly exposed.
For cloud credentials, our data shows a marked upward trend. In 2023, valid cloud credentials accounted for just under 10% of all still-active exposed secrets. By 2024, that share had surged to almost 16%. This increase likely reflects the growing adoption of cloud infrastructure and SaaS in enterprise environments, but it also underscores the ongoing struggle many organizations face in managing cloud access securely—especially as developer velocity and complexity increase.
In contrast, database credential exposures moved in the opposite direction. In 2023, valid database credentials made up over 13% of the unremediated secrets detected, but by 2024, that figure dropped to less than 7%. This decline could indicate that awareness and remediation efforts around database credentials—particularly following high-profile breaches and increased use of managed database services—are starting to pay off.
The overall takeaway is nuanced: while organizations may be getting better at protecting traditional database secrets, the rapid rise in valid, unremediated cloud credential exposures suggests that new types of secrets are taking their place as the most prevalent and risky. As cloud-native architectures become the norm, the need for automated secrets management, short-lived credentials, and rapid remediation is more urgent than ever.
Practical Remediation Strategies for High-Risk Credentials
MongoDB credentials
To reduce the risk posed by exposed MongoDB credentials, organizations should act quickly to rotate any that may have leaked and set up IP allowlisting to strictly limit who can access the database. Enabling audit logging is also key for detecting suspicious activity in real time and helping with investigations after a breach. For longer-term security, move away from hardcoded passwords by leveraging dynamic secrets. If you use MongoDB Atlas, programmatic access to the password rotation is possible through the API so that you can make your CI/CD pipelines routinely rotate secrets, even if you haven't detected an exposure.
Google Cloud Keys
If a Google Cloud key is ever found exposed, the safest move is immediate revocation. To prevent future risk, transition from static service account keys to modern, short-lived authentication methods: use Workload Identity Federation for external workloads, attach service accounts directly to Google Cloud resources, or implement service account impersonation when user access is required. Enforce regular key rotation and apply least privilege principles to all service accounts to minimize the potential impact of any exposure.
AWS IAM Credentials
For AWS IAM credentials, immediate rotation is essential if exposure is suspected. The best long-term defense is to eliminate long-lived user access keys entirely, opting for IAM Roles and AWS STS to provide temporary credentials for workloads. For systems outside AWS, leverage IAM Roles Anywhere. Routinely audit your access policies with AWS IAM Access Analyzer and enable AWS CloudTrail for comprehensive logging, so you can quickly spot and respond to any suspicious credential usage.
By adopting these modern secrets management practices—focusing on short-lived, dynamic credentials and automation—organizations can significantly reduce the risks posed by exposed secrets and make remediation a routine, manageable process rather than a fire drill.
Secret managers integrations can also facilitate this task.
Conclusion
The persistent validity of exposed secrets represents a significant and often overlooked security risk. While detection is essential, organizations must prioritize rapid remediation and shift toward architectures that minimize the impact of credential exposure.
As our data shows, the problem is getting worse, not better—with more secrets remaining valid longer after exposure. By implementing proper secret management practices and moving away from long-lived credentials, organizations can significantly reduce their attack surface and mitigate the impact of inevitable exposures.
