Detecting leaked credentials is only half of the battle. The real challenge, and in many cases half of the equation is ignored, is what happens after detection. A new study from Gitguardian’s State of Secrets Sprawl 2025 report reveals disturbing trends. Most of the publicly available company secrets remain effective in most of the companies secrets discovered for years after detection, expanding the attack surface that many organizations have not dealt with.
A surprising percentage of credentials detected back to 2022 remains valid today, according to an analysis of exposed secrets across Gitguardian’s public Github repository.
“Detecting leaked secrets is just the first step,” says Gitguardian researchers. “The real challenge lies in quick fixes.”
Why the exposed secrets remain valid
This persistent validity suggests two troubling possibilities. Which organization is unaware that their credentials are publicly available (security visibility issues) or lacking the resources, processes, or urgency to properly fix them (security operational issues). In both cases, the concern is that these secrets are not routinely revoked automatically from their default expiration dates or manually as part of a normal rotation procedure.
Organizations either do not recognize publicly available credentials or lack the resources to effectively deal with them. Hardcoded secrets multiply throughout the codebase and challenge comprehensive repairs. Secret Rotation requires coordinated service and system-wide updates, which often affect production.
Resource constraints enforce prioritization of only the highest risk exposure, but legacy systems create technical barriers by not supporting modern approaches like short-lived qualifications.
This combination of limited visibility, operational complexity, and technical limitations explains why hard-coded secrets often remain valid for a long time after exposure. Moving to Modern Secrets Security Solutions with centralized, automated systems and short-lived credentials is not just a security best practice, it is an operational need.
Which services are at the most risk? trend
Behind the raw statistics is an astonishing reality. Critical production systems remain vulnerable as their public repositories exposes their credentials for years to come.
An analysis of exposed secrets in 2022-2024 revealed that database credentials, cloud keys, and API tokens for essential services remain valid for a long time after initial exposure. These are not test or development qualifications, but the real keys of the production environment, representing the direct pathways for attackers to access sensitive customer data, infrastructure, and business critical systems.
Sensitive services are still publicly available (2022–2024):
MongoDB: Attackers can use these to remove or corrupt data. These are highly sensitive and provide access to personally identifiable information or technical insights that potential attackers can use for privilege escalation or lateral movement. Google Cloud, AWS, Tencent Cloud: These cloud keys allow potential attackers to access infrastructure, code, and customer data. mysql/postgresql: These database credentials also persist in public code every year.
These are not test credentials, they are keys to live services.
Over the past three years, the exposed secret landscape of public repositories has changed in ways that reveal both the progress and new risks of cloud and database credentials, particularly in the cloud and database. Again, these trends have been discovered and only reflect those that are still effective. This means that despite public exposure, they have not been improved or cancelled.
For cloud credentials, the data shows a significant upward trend. In 2023, valid cloud credentials accounted for less than 10% of all exposed secrets still active. By 2024, its share had skyrocketed to almost 16%. This increase may reflect an increase in cloud infrastructure and SAAS adoption in enterprise environments, but highlights the ongoing struggles many organizations face when managing cloud access securely, particularly with increasing speed and complexity among developers.
In contrast, database credential exposures moved in the opposite direction. In 2023, valid database credentials accounted for more than 13% of unlit secrets found, but by 2024 that figure had fallen below 7%. This decline could indicate that database credential awareness and repair efforts, particularly those that are beginning to pay off, with increased use of well-known breaches and managed database services.
Overall takeout is a bit tricky. While organizations may have improved protection of traditional database secrets, the rapid increase in cloud qualification exposures, which are not well known, suggests that new types of secrets are the most common and dangerous positions. As cloud-native architectures become the norm, the need for automated secret management, short-lived qualifications, and quick repairs is more urgent than ever.
A practical remediation strategy for high-risk credentials
To reduce the risk poses of exposed MongoDB qualifications, organizations need to rotate what may have been leaked and act quickly to set up IP AllowListing to strictly restrict anyone with access to the database. Enabling audit logs is also key to detecting suspicious activity in real time and assisting in post-violation investigations. For long-term security, you can move away from hardcoded passwords by leveraging dynamic secrets. When using Mongodb Atlas, you can programmatically access password rotation through the API, allowing you to rotate the secret periodically, even if no exposure is detected in the CI/CD pipeline.
Google Cloud Key
If you find that your Google Cloud Key is exposed, the safest move is immediate revocation. To prevent future risks, migrate from static service account keys to the latest short-lived authentication methods: use workload identity federation for external workloads, attach service accounts directly to Google cloud resources, or implement impersonation of service accounts when user access is required. Perform a normal key rotation and apply minimal privilege principles to all service accounts to minimize the potential impact of exposure.
AWS IAM Credentials
For AWS IAM credentials, immediate rotation is essential if exposure is suspected. The best long-term defense is to choose IAM role and AWS STS to completely eliminate long-lived user access keys and provide temporary credentials for your workload. For systems other than AWS, take advantage of the IAM role everywhere. You can use AWS IAM Access Analyzer to routinely audit your access policies and enable AWS CloudTrail for comprehensive logging, allowing you to quickly find and respond to suspicious credentials.
By adopting these modern secret management practices, by focusing on short-lived, dynamic credentials and automation, organisation can significantly reduce the risk poses from exposed secrets and make remedies a routine and manageable process rather than fire drills.
Secret Manager integration also helps to resolve this task automatically.
Conclusion
The persistent validity of exposed secrets represents a critical and often overlooked security risk. Discovery is essential, but organizations should prioritize rapid remediation and migration to architectures that minimize the impact of qualification exposure.
As our data shows, the problem is worse and not better. Even after exposure, there are more effective secrets that are effective for a long time. Implementing appropriate secret management practices and leaving long-lived credentials can significantly reduce the attack surface and reduce the impact of inevitable exposure.
Gitguardian’s State of Secrets Sprawl 2025 report provides a comprehensive analysis of secret exposure trends and remediation strategies. The full report is available at www.gitguardian.com/files/the-tate-of-secrets-sprawl-report-2025.
Source link
