It’s 2025. Let’s Talk About Secrets Sprawl

GitGuardian released their 2025 State of Secrets Sprawl Report this month, and it’s sobering. 

The number of secrets leaked in public GitHub repositories keeps growing. GitGuardian found 23.8 million new credentials, which is a 25% year-over-year increase. 

An even more telling number is that 70% of secrets leaked in 2022 remain active. This is both worrisome, and not surprising. 

For starters, we’ve seen a large increase in both the types and the number of secrets. Cloud services from providers like AWS, Software as a Service (SaaS) like Salesforce, and APIs from Claude or OpenAI each come with their own types of credentials, and whether we call them access keys, API keys, or passwords, we have to keep them secret. 

To make things worse, a successful application makes these secrets difficult to rotate. Once our applications are serving customers and handling transactions, the last thing we want to do is risk an outage. Manually rotating a secret safely across busy systems is an intrusive project, and it takes a long time.

Secret managers are a useful tool to cope with the problem. They centralize control and provide visibility. But while this helps us understand the problem, it doesn’t solve it. Secret managers come with their own authentication requirements, too.

This is one of those times where we have to reframe the problem. By focusing on secrets, we’re ignoring identity. That is, we’re trying to manage access to resources without first ensuring that this access is gated by predictable and trustworthy identities. As an analogy, a speakeasy where everyone uses the same password is a fun way to run a bar. But it’s not how we decide who comes into our organization’s offices. We issue badges to our employees, and visitor badges to their guests. In both cases, we verify their identities first.

This is what we have to do with our machine workloads as well. They’re very different from people, or human identities, in that they’re ephemeral: They’re around for hours or days, instead of years. So their identity documents should be valid for shorter times as well. This means that credential rotation is not something we do “in case of emergency.” Instead, we are constantly rotating credentials – every hour, every day.

This identification and rotation is built into the underlying infrastructure. The average developer doesn’t have to care about it, just as they don’t have to care about the color of the networking cables in the datacenter. But it lets them access resources using constantly-refreshed identities, instead of long-lasting secrets. 

From the CISO’s perspective, the difference is clear. The exposure of a static credential is a disaster, and its rotation is intrusive, dangerous, and costly. A short-lived identity document, on the other hand, is likely to be rotated even before its exposure is detected. If not, rotation is a click away.

Beyond the blast radius, the sheer number of secrets is reduced by using machine identity standards like SPIFFE to authenticate. Instead of a collection of secrets, we can use one or two, depending on the format required. Even if we can’t eliminate every secret, we protect them with a secret manager, and then use a SPIFFE identity to access the secrets manager.

To stop secrets sprawl, it is time to rethink workload authentication. Taking an identity-first approach underpinned by open standards like SPIFFE and WIMSE allows workloads to authenticate securely and integrate easily with existing systems while removing the need to provision them with long lived secrets. 

It’s 2025. Next time you need a secret, use a machine identity instead!

SPIRL uses open standards to unify fragmented machine identities across all your environments so that you don’t have to manage more secrets. Learn more. 

‍