Before GitGuardian was a company, it was a side project. We were two data scientists looking for the answer to one question: how prevalent were leaked secrets on GitHub? So we built a system that scanned every public commit in real time. The scale of what people were exposing—passwords, cloud keys, the credentials that run real businesses—was far larger than we could have imagined.

The first product we ever shipped did not make us a cent. It sent an email. When our system saw a developer expose a secret in public, it told them, so they could revoke it before someone else used it. We called it the Good Samaritan Program. For eight years, it has done one thing: warn strangers, thousands of times a day. That email is how a lot of people first met GitGuardian, and it helped make us the most installed security application on the GitHub Marketplace.

The missing piece was scale

For most of those nine years, the program reached individuals. But many of those individuals work inside larger enterprises, and many of the secrets they expose do not belong to them personally. Some leaks are a solo developer’s personal API key. Many others are enterprise credentials: cloud keys, database passwords, and tokens for systems the developer may not even own, pushed to a personal repository by an employee or contractor.

Warning a single developer is easy to automate. It is also not enough to stop the sprawl. 64% of the credentials that were valid in 2022 were still unrevoked four years later. We realized the developer alone was never going to be enough. To close exposures like these, we had to reach the organization that owned the credential.

The hard part was attribution. Connecting a leaked secret to a developer, and then connecting that developer to the right company, was slow, manual work. We could do it, but only a handful of times.

That has changed. In 2025 alone, 28.65 million new secrets were pushed to public GitHub, a 34% jump in a single year and the largest we have ever recorded. The same force behind that number, AI putting more code in more hands faster, is also what now lets us attribute an exposed secret to the organization it belongs to and route it to the right people. The thing making the problem worse turns out to be the thing that lets us help more.

So we pointed it at the warning and built a second program. The original Good Samaritan Program warns the developer who leaked a secret. The Enterprise Good Samaritan Program warns the company the secret belongs to.

That sounds simple in one sentence. It is not. Attributing a single leak means starting with a credential sitting in a stranger’s public repository and figuring out which organization it belongs to, whether it is real, and how much access it grants. Doing that once takes judgment. Doing it at scale takes infrastructure. We are working across 370M+ historical exposures and 80k+ new exposures every day, which means attribution cannot depend on human review alone. It takes AI agents to handle the early triage, and human researchers to focus on the most critical leaks.

We are investing in that system because it is what lets the program scale without losing the judgment, restraint, and accountability it depends on. When attribution lands, we work to get the warning in front of someone who can act on it, escalating by hand when an automated alert goes nowhere. And we do all of it under a published set of rules for what we will and will not do with a credential find.

Why we still call it “Good Samaritan”

In the story, the Samaritan stops for a stranger he has no reason to help, and no one would have blamed him for walking on.

We are in that position. We can see, in real time, leaks that belong to companies who have never heard of us and may never pay us. We can keep walking, because their exposure is not technically our problem. Or we can tell them. We made that choice early, and we have not changed our minds since.

The warning doesn't depend on what you do next

I know how this can sound coming from a security vendor. A free warning, from a company that also sells security software, can look like marketing with extra steps. It is a fair suspicion, and I won't pretend we aren't a business.

Here is what I can tell you. The warning is complete and unconditional. When we contact you about an exposed secret, you get everything we know: where it leaked, whether it's valid, what it can reach, whether or not you ever speak to us again. There is no gated version, no teaser, no "book a call to learn more." Some companies we've warned later became customers. Most never will, and we keep warning them anyway.

Make yourself reachable

If I could ask one thing of any security leader reading this, it is small, and it is free: make sure your company has a way to hear it when an outsider finds your exposed secret. Today, a serious disclosure too often lands in a generic contact form, or a bug-bounty queue built to reject anything that is not a classic vulnerability. Our warning arrives, and then it dies in the wrong inbox.

You need a door, and someone behind it.

We will keep knocking either way. We did it for CISA, and for companies like Oracle, IBM, SAP, and Red Hat, whose security teams have credited our researchers in their halls of fame. And will keep doing it. Because we did not build a business and then decide to do some good on the side. The good came first. The company grew up around it.

And, by the way, you don't have to wait for us to find you. See whether your company's credentials have already been exposed on public GitHub with our GitHub Security Audit.

From Alert to Action: Best Practices to Handle Responsible Disclosure

Responsible disclosure is an often overlooked but critical component of cybersecurity alerting processes. Explore key best practices that can enhance communication and collaboration with researchers, turning potential security threats into opportunities for stronger defense.

GitGuardian Blog - Take Control of Your Secrets SecurityGaetan Ferry

Your Secrets Need a VDP, Not Just a Bug Bounty

Bug bounty programs are valuable—until they replace disclosure policies. Learn how unreasonable PoC demands or scope exclusions create security blind spots when it comes to leaked secrets.

GitGuardian Blog - Take Control of Your Secrets SecurityGaetan Ferry