What 29 Million Leaked Secrets Mean for Your Identity Program [Introductory]

Hello everyone, I'm Stanislas Crepin, I'm the Director of Solutions Engineering at GitGuardian and today we're going to talk to you about the state of secret sprawl for 2026. This is basically a study done by our marketing team at GitGuardian where they publish every year a report explaining what we see in terms of trends and when it comes to secret sprawl.

So first, a question, what are secrets? Well, secrets are the authentication parts of NHIs, if you want, non-human identities. Non-human identities, we tend to define them as a combination of a system, the authentication key to a system, so private keys, API keys, credentials, tokens, whatever manages the authentication and the permission set that is associated with those, the scope of the secret, if you want. What do we do now? Historically, we've been monitoring public GitHub, so everything that gets committed and pushed to public GitHub, we scan it.

Now, two options. Option one, at the top, we find no secrets in the commit screen. Option two, we find something. So we find a key, an API key, a generic secret, or even multiple of those, AWS keys, GitHub PATs.

Typically, what we do when we find one of those is we try to alert the person finding it. If he's working for one of our customers, we alert our customer as well. And this is something we do in public GitHub since 2018. We do it on a few other sources as well, and we do it in the internal sources of our customers. Question to the audience, have you ever leaked a secret? It's not a name and shame. I would say if you have leaked a secret, know that, I would say, almost everyone does it at some point. It's not a catastrophe, but you have to be aware of it. You have to realize what you've done.

In fact, most of the people leaking secrets don't do it voluntarily. Of course, they do it because they don't realize that there is a secret hidden in the code or in the files that they pushed. How leaky was 2025? On public GitHub, we saw almost 29 million of secrets being leaked in 2025. That's a 34% increase over the previous year. This is something that increases every year. And around 6% of the public repositories contain at least one hard-coded secret. So you can see the evolution over the years here.

In 2021, it started pretty small when you compare it to 2025. What's interesting is that there were 2 billion public commits in 2025, and roughly, on average, 1.5 secrets per 1,000 commits. So secrets, the growth rate of leaked secrets grows faster than the developer population, meaning we leak now more secrets in 2026 than we leaked in 2021 per developer per commit. What's also interesting is that we are observing a remediation gap. For the secrets that we can test, we do validity checks, meaning we check if they're still valid.

What's interesting is that when we see secrets leaking publicly, they stay valid. So there is no remediation action taken in an important share of the secrets being leaked.

Of course, if we look at historical data, there's now more secrets that are invalid, just because in a lot of cases, the secrets are scoped to become invalid after a specific amount of years, hopefully. And in some cases, the leaker realizes, oops, I made a mistake, and he remediates it.

But still, you can see in 2022, for the secrets on which we have validity checks, 64% are still valid as of today. That's not great. What's also extremely interesting is that we have visibility on both public activity and through our customers and prospects, we also have visibility on activity inside their private repositories. And I would say people make mistakes when they leak publicly.

But still, in their mind, they usually know that they are doing things in public. So they try to avoid having secrets in the code. They try to avoid having valid secrets in the code.

It's much, much less the case when people are working within internal systems. They assume we are safe, so they take less precautions. They have a tendency to leak more secrets inside internal repositories. Is it a bad thing? Kind of. The thing is, because they assume they're safe, I think they're leaking six times more secrets inside internal repositories. So that means internal repositories are a gold mine for attackers. And it's not just internal repositories. It's Docker registries as well. It's internal collaboration tools. All of these can contain secrets.

And of course, sometimes when we talk to people, they tell us, hey, but these are internal, so we're safe. Spoiler alert, you're not. You are until you get breached or until you have a bad actor in the company.

So really, internal repositories, internal data sources should be cleaned of secrets as much as possible. You should not assume you're safe because it's internal. I was mentioning it. We find secrets in source code, but we also find secrets in collaboration tools.

Teams, Slack, SharePoint, basically anywhere where developer teams can collaborate, there's a tendency to leak secrets. What's also quite interesting is that even if we find less secrets inside these collaboration tools, typically the secrets we found at the intersection of both, so secrets that are found both in source code and in collaboration tools, have a tendency to be more critical and more valid than secrets that are found in just one of these sources. We're all here because we are interested by the identity and AI topics.

And what's interesting when it comes to non-human identities and AI is that 2025 was a year where AI activity or AI development activity exploded, became even more mainstream than when it was, and we're going to see the impact of this. We saw a massive, massive surge in leakage of AI-related secrets. What you see here is the top detectors, the top type of detectors leaking new secrets in 2025 in terms of growth. The ones in red are the ones that are AI-related. They represent the vast majority of the ones highlighting a massive growth.

It can be multi-modal platforms like open router, orchestration workflows for AI agents, tracking of API embeddings, etc., etc. We really see a massive increase in adoption and that leads to a massive increase in secrets leakage. We've also identified a new source of leak, unfortunately. As you know, when your teams are working with AI agents, they also use MCPs to connect to different services and the configuration files for those MCPs contain secrets. And we see quite a few of those getting pushed to public GitHub with the secrets still in there.

So, a massive source of new leaks for us. You can see here the top valid unique secrets in MCP configuration file per month and the top five type of valid secrets found within those files.

So, PGSQL database connection strings, Google API keys, Perplexity API keys, Brave Search, and Firecall API keys at the top. Lastly, when it comes to the impact of AI, one thing that is interesting is that AI agents themselves leak keys.

We saw, of course, more and more code being committed by the AI agents. And on average, I mentioned it earlier in the presentation, 1.5% of commits contain secrets. For AI agents, if we look at the activity of cloud code specifically, on average, we were at 3.2%.

So, a bit more leaky than a human. And you can see here the average rates per 1,000 commits containing secrets per month.

So, it evolves over time, potentially because the model evolves and it leaks more or less secrets depending on how its performance evolves. But overall, we were still at a higher leak rate than a human.

So, the agents are very interesting. They can be improved and they also have a tendency to leak secrets on their own.

So, we need to have some visibility on this. Also, a question for the audience. Do you typically allow your coding assistant agents like Cloud to code all your commits or do you always double check the content of the commits before allowing them? It's food for thought, I would say.

And also, there's also the possibility that you don't use an AI coding assistant, but I think this has become mainstream, as we've seen in the previous slides. Now, another evolution that we've seen is that we need – this has been a topic for a few years now – we need to shift left. We need to get closer to the source because it's easier from a remediation standpoint, but also because attackers themselves are getting closer to the source. We are seeing the developer workstation becoming more and more of a target for attackers.

You can see here a list of security events that were tied to developer workstations. We really see an acceleration in particular in the last few months, honestly. If you follow the news, it's right now quite crazy. It's almost every week there is a new event around developers being attacked, NPM dependencies being poisoned and injected with malware that then targets the developer workstation by scanning the content of the workstation for credentials and then exfiltrating the credentials.

One of the most famous recent ones, ShyHollywood – I don't know if you've heard of it, but it was a couple of months ago. Just the scenarios that I described, NPM packages being poisoned, developers downloading these packages, the malware executing on the machine of the developers, gathering credentials and publishing them openly on public GitHub. We did analysis of what we found. We also contacted every company that we found that had been impacted by ShyHollywood to give them our findings to help them remediate.

Overall, what we found was that the machines of the developers were filled with secrets, these secrets being exfiltrated by ShyHollywood. A lot of those were valid secrets and also high-privileged secrets. We found close to 600 PATs in there, close to 400 OAuth tokens, 100 fine-grained PATs and more than 100 GitLab tokens. As I mentioned, we contacted every company that we managed to identify that had those tokens and those leaks due to ShyHollywood to give them the list of what we had found publicly and help them remediate.

But these are almost a common occurrence as of today, this type of attacks. The source code for ShyHollywood has been open-sourced by the attacker group that created it. So now we are also seeing mini-ShyHollywood happening quite regularly. One thing that is interesting and to keep in mind when you want to prioritize secret incidents is that you cannot just rely on the validity. The validity is an extremely interesting indicator because, of course, if you have a valid secret versus an invalid one, you're going to want to take a look at the valid one first.

But the problem is that a lot of critical secrets do not have a validity status associated with them because they are considered like generic secrets. They use validity checks that are not available in GitGuardian platform or in other platforms because they are specific to your organization. So as you can see here, for the secrets found on GitLab and Docker, we had between 70% and 80% of secrets for which we did not have validity check results.

And yet, among those 70 or 80%, there's a quite important share of critical secrets for organizations. So we need to keep this in mind and not solely rely on the validity checks. One thing also that is important is that when we look not just at secrets but at the broader picture and look at the non-human identities themselves, we see breaches of policies when it comes to governance and by far the most common one we see is long-lived secrets. 60% of the issues we flag when monitoring non-human identities inventories are tied to this type of policy breach. Non-human identities are not passwords.

There's no official recommendation not to rotate them, quite the contrary. They should be rotated often.

And yet, 60% of the breaches we see when it comes to non-human identities governance is tied to identities that are not rotated often enough. And the vast majority of what we see in terms of policy breach, the rest is duplication, meaning identities that are present across different vaults and internal leakage, meaning identities whose credentials end up leaked in collaboration tools or VCS.

Now, what this means for your non-human identity governance and security program, the first thing is that the absolute priority should be mapping every NHI you have in your environments. You need to be able to know where they are, what they're being used for in which environments, and also a particular question that needs to be asked, who owns them? You need to be able to associate a non-human identity to a human to have attribution, ownership, and accountability of these identities. Second important insight I would say, you need to treat your internal repos as first-class leak sources.

As I mentioned, they're gold mines for attackers. You want to ensure that these gold mines are as dry as possible and that they are not leaving valuable clues for attackers to move laterally.

Really, when we see companies being breached, one of the first things the attackers do is scan the VCS, scan the Slack history, and look for secrets using scanners. You need to include the developer workstation in your scanning coverage, because as I mentioned, we see more and more attacks targeting the developers, also because the developers themselves are having more and more access rights, more and more credentials directly on their machines with the rise of AI agents, with the use of MCP servers, etc. So they're prime targets really for attackers.

You need to take this into account and to ensure that you have visibility on what's happening on their machines. You need to extend detection beyond code, as I was mentioning, so not just the VCS but also the collaboration tools, and you need to stop prioritizing by validation status alone. And when it comes to bridging the remediation gap itself, you will want to leverage vaults and automate rotation, but be aware of vaults. You don't want to have dozens and dozens of vaults coexisting in your organization. From a governance standpoint, it's going to be a nightmare.

You're going to have the same credentials stored in different vaults, so you'll never... it's going to be extremely complicated to ensure that you have the same secret associated to the same credential across those vaults. You need to establish MCP and AI tooling and policies. You'll also want to audit and harden your self-hosted infrastructure, because even on your self-hosted servers, you can have credentials deployed, and basically, if an attacker manages to get in those, they will also be able to gather those credentials.

And generally speaking, and this is a comment that is good whenever it comes to NHI, you want to reduce the usage of static credentials and adopt short-lived identity-driven access whenever possible. You saw that 60% of the policy breach when it comes to NHI were long-lived tokens. We think this should be fairly easy to circumvent and to establish a baseline of having short-lived credentials as much as possible. That marks the end of this presentation. I hope you learned some useful things.

If you have any questions, you can contact us on this email address, but also on the booth that we have in the NHI pavilion just outside of the building. Thank you, everyone. Thank you.