The Persistence Problem: Why Exposed Credentials Remain Unfixed—and How to Change That

Detecting leaked credentials is only half the battle. The real challenge—and often the neglected half of the equation—is what happens after detection. New research from GitGuardian’s State of Secrets Sprawl 2025 report reveals a disturbing trend: the vast majority of exposed company secrets discovered in public repositories remain valid for years after detection, creating an expanding attack surface that many organizations are failing to address.

According to GitGuardian’s analysis of exposed secrets across public GitHub repositories, an alarming percentage of credentials detected as far back as 2022 remain valid today:

“Detecting a leaked secret is just the first step,” says GitGuardian’s research team. “The true challenge lies in swift remediation.”

Why Exposed Secrets Remain Valid

This persistent validity suggests two troubling possibilities: either organizations are unaware their credentials have been exposed (a security visibility problem), or they lack the resources, processes, or urgency to properly remediate them (a security operations problem). In both cases, a concerning observation is that those secrets are not even routinely revoked, neither automatically from default expiration, nor manually as part of regular rotation procedures.

Organizations either 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.

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.

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: Attackers can use these 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, AWS, Tencent Cloud: these cloud keys grant potential attackers access to infrastructure, code, and customer data.
• MySQL/PostgreSQL: these 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, the 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

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 help to solve this task automatically.

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.

GitGuardian’s State of Secrets Sprawl 2025 report provides a comprehensive analysis of secrets exposure trends and remediation strategies. The full report is available at www.gitguardian.com/files/the-state-of-secrets-sprawl-report-2025.

Found this article interesting? This article is a contributed piece from one of our valued partners. Follow us on Twitter  and LinkedIn to read more exclusive content we post.

Some parts of this article are sourced from:
thehackernews.com