The Case for Credentials That Expire

Every year, GitGuardian publishes its State of Secrets Sprawl report. Every year, the numbers get worse. In 2024, GitGuardian detected 23.8 million new hardcoded secrets in public GitHub repositories - a 25% increase over the previous year, based on analysis of 1.4 billion commits.^[1] That figure does not include private repositories, CI/CD pipelines, Slack channels, or Jira tickets. It is only what was visible in public code.

The volume of leaks is bad. The persistence of those leaks is worse. According to the same report, 70% of secrets leaked in 2022 remain active today.^[3] The credential a developer accidentally committed three years ago is, in most cases, still valid. Attackers do not need to find new leaks - they can mine old ones.

The security industry has responded with better detection tooling. GitHub Push Protection now blocks many known secret patterns at the point of commit. GitGuardian, Trufflehog, and similar tools scan repositories continuously. And yet the numbers keep climbing. Detection is not solving the problem because detection is not where the problem starts.

The persistence problem is the real problem

When a secret leaks into a public repository, three things typically happen. A developer notices (or a scanner alerts them). The file is edited or the commit is reverted. The developer assumes the threat is contained.

It usually isn't. GitHub's commit history means that deleted content often remains accessible via the API or through cached forks. More importantly - and this is the critical finding from GitGuardian's research - most leaked credentials are never revoked.^[3] Developers fix the leak in the repository without invalidating the underlying credential. The secret is gone from the codebase. It is still alive in the system it authenticates against.

This is the persistence problem. The attack surface does not shrink when a leak is discovered. It keeps expanding, accumulating every credential that was ever exposed and never rotated. Attackers cataloguing public GitHub leaks are operating against a growing inventory of valid credentials, not a static snapshot.

The 2024 U.S. Treasury Department breach illustrates this precisely. The breach was traced to a single leaked API key for BeyondTrust's authentication platform - an exposed credential that bypassed what the Treasury had invested millions of dollars in securing.^[3] As GitGuardian CEO Eric Fourrier noted: unlike zero-day exploits, attackers exploiting leaked secrets don't need advanced skills. They just need one valid credential.^[3]

Secrets sprawl is not just a code problem

The 23.8 million figure covers public GitHub alone. The full scope of secrets sprawl is considerably larger, because developers share credentials in many more places than code repositories.

GitGuardian's 2025 report expanded its investigation into collaboration tools and found alarming results. 2.4% of corporate Slack channels contained leaked secrets. More critically, 6.1% of Jira tickets exposed credentials - making Jira the single most vulnerable collaboration tool in the analysis.^[5] DockerHub compounds the problem further: GitGuardian's scan of 15 million public Docker images uncovered 100,000 valid secrets, with 98% embedded in image layers rather than exposed in source code.^[1]

The implication is significant. An organisation could have comprehensive repository scanning in place and still be haemorrhaging credentials through the tools its team uses every day. The developer who pastes a database connection string into a Jira ticket to help a colleague debug a staging issue is creating a credential exposure that no code scanner will ever find. That ticket persists indefinitely, indexed and searchable by anyone with Jira access - including former employees on legacy accounts.

This is why we've previously written about the specific risk of sharing sensitive credentials over Slack - the problem is architectural. Platforms built for permanent retention are fundamentally at odds with credentials that should have a short useful life.

Private repositories are not safe either

A common assumption is that secrets in private repositories are inherently safe. GitGuardian's data directly contradicts this. The report found that 35% of scanned private repositories contain at least one plaintext secret.^[4] AWS IAM keys appear in 8% of private repositories - five times more frequently than in public ones (1.5%). Hardcoded passwords appear nearly three times more often in private repositories (24%) than public ones (9%).^[1]

The pattern suggests that developers treat private repositories as safe storage for credentials rather than code. The implicit assumption that "it's private, so it's secure" leads to worse security hygiene, not better. Private access restrictions do not equal data protection. A compromised account, a misconfigured repository permission, or an overly broad OAuth scope grants an attacker the same access to private credentials as any team member.

AI coding assistants are making it worse

GitHub Copilot usage increased by 27% between 2023 and 2024.^[2] The impact on secrets exposure is measurable. GitGuardian found that public repositories where Copilot is active had a 6.4% secret leakage rate - roughly 40% higher than the 4.6% rate observed across all public repositories, based on a sample of approximately 20,000 Copilot-active repositories.^[2]

The 6.4% vs 4.6% disparity likely reflects two dynamics. AI-generated code may suggest credential patterns that developers accept without scrutiny. More broadly, coding assistants optimise for development velocity in a way that can deprioritise security review. Copilot is an exceptional productivity tool. Its adoption has also measurably correlated with an increased rate of credential exposure in the repositories where it is used.

As AI coding tools become the default development environment, the credentials handling patterns they encourage will have a material effect on the industry's aggregate security posture.

Secrets managers help - but they don't cover the sharing layer

The obvious prescription for secrets sprawl is to use a dedicated secrets manager: HashiCorp Vault, AWS Secrets Manager, Infisical, Doppler, or one of the many alternatives. These tools are genuinely valuable. They centralise credential storage, enforce rotation, provide audit logs, and eliminate hardcoded credentials from application code.

But GitGuardian's 2025 report contains a sobering data point: organisations using dedicated secrets managers still had a 5.1% secret leakage rate.^[1] Vaults solve the machine-to-machine credential problem. They do not solve the human-to-human sharing problem.

The scenario plays out constantly. A developer needs to give a contractor temporary access to a staging database. The contractor isn't on the company's vault. The developer copies the connection string and sends it via Slack. A new team member joins and needs an API key for the internal tooling before their Vault access is provisioned. Someone emails it to them. An on-call engineer needs emergency credentials at 2am - the fastest path is a direct message.

These are not failures of policy. They are failures of infrastructure. When the secure option is slower than the insecure one, people default to the insecure option. The solution is not to make the vault faster - it is to make the sharing layer safe by design. We cover this in more detail in our guide to credential lifecycle management, and in our analysis of when secrets managers alone aren't enough.

The missing layer: credentials that expire by design

The persistence problem has a structural solution. If shared credentials expire automatically - if they cannot exist beyond the window of time they were needed - the attack surface doesn't accumulate. A credential shared ephemerally and viewed once is gone. It cannot be discovered in a breach three years later. It cannot be harvested from a Slack archive. It cannot appear in a Jira ticket that survives a change in access controls.

This is the principle behind ephemeral sharing: not better detection of leaked credentials, but elimination of the conditions that make leaked credentials dangerous over time. The data that no longer exists cannot be breached.

Ephemeral sharing complements secrets managers, not replaces them. The vault handles production credentials, automated rotation, and machine identities. Ephemeral sharing handles the human layer: the contractor onboarding, the debugging session, the emergency handoff, the staging credential that needs to reach one person for one task. For each of those cases, the credential should exist for as long as it is needed and disappear the moment it isn't.

What this looks like in practice

The workflow change is minimal. Instead of pasting a credential into Slack or email, a developer creates an ephemeral share - a link that expires after a configurable window (one hour, one day, one view) and is deleted from storage when it does. The recipient opens the link, retrieves the credential, and the link is gone. There is no audit trail of the credential content in Slack's message history, no copy sitting in an email archive, no version history in a shared document.

For teams building this into existing workflows, ZeroHost supports a REST API and a ZeroHost API suitable for CI/CD integration. The CLI allows developers to pipe credential content directly from the terminal into an ephemeral share without touching a browser.

The operational overhead is comparable to generating a shortened link. The security outcome is categorically different: the credential is structurally incapable of persisting beyond its intended use. That property is what detection alone cannot deliver.

The takeaway

23.8 million secrets leaked on public GitHub in 2024. 70% of secrets from 2022 still active. 5.1% leakage rates even in organisations with dedicated secrets managers. These numbers describe an industry that has invested heavily in detection and not enough in the structural conditions that make leaked credentials long-lived.

Better scanners are necessary. They are not sufficient. The piece missing from most security stacks is a sharing layer that enforces expiry - that makes it structurally impossible for a shared credential to outlive its purpose.

The most secure credential is one that no longer exists. Ephemeral sharing is how you get there.

Share a secret with ZeroHost - no account required, zero data retention, automatic expiry.