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.
Our agents are now able to screen more than a million public incidents a month and investigate over 100,000 of them in depth. At its best, manual review handled a few hundred leaks a week. Today, agents analyze 99,9% of eligible public incidents we detect globally, 10x faster and at half the cost. That speed leaves researchers time for the leaks that need human judgment.
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.
FAQ
What is an Enterprise Good Samaritan Program from GitGuardian?
Since 2018, GitGuardian's Good Samaritan Program has scanned public GitHub in real time and warned developers, for free, when they exposed a secret. Years of alerts taught us that warning the developer isn't enough. Many of the secrets they expose belong to their employer: cloud keys, database passwords, production tokens. Most are never revoked: 64% of valid secrets found in 2022 were still active in 2026.
The Enterprise Good Samaritan Program alerts the organization instead. It focuses on large companies and public institutions, where one leaked credential can expose production systems or customer data. Alerts go to the security teams who can act: CISOs, AppSec, and SOC teams. The goal is to revoke the secret. Each alert explains where the secret leaked, what it can reach, and how to shut it down.
How does the Enterprise Good Samaritan Program work?
We monitor public GitHub and Docker Hub continuously. When we find an exposed credential, our engine works out which organization it belongs to. Then it checks how critical the leak is: is the credential valid, is it still public, and what can it reach? If the leak is serious, we contact your security team directly. We share everything we found: where it leaked, whether it's live, and the attack path it opens. We don't ask for anything in return. We just want you to have what you need to revoke the secret before someone else uses it.
Who is the Enterprise Good Samaritan Program for?
It's for any organization whose credentials have been exposed in public: companies, public institutions, and nonprofits. You don't need to be a GitGuardian customer. We contact the people who can act: CISOs and the AppSec, security operations, and incident response teams. We only alert on secrets we can attribute to your organization, that are valid or likely valid, and that give access to systems or sensitive data. The original Good Samaritan Program continues to warn individual developers.
What to do if you receive an alert?
Each alert contains everything you need to act right away, no call or sign-up required. Revoke or rotate the credential first: deleting the commit isn't enough, because the secret stays in the history and may already have been copied. Then check your logs for any use of the credential since the leak date, and find where it came from to see whether the same repository holds other secrets.
If you'd like a second opinion, our security researchers are happy to walk you through what we found. And there's no shame in it: leaks happen to every organization.
Is GitGuardian legitimate?
Yes. GitGuardian is a cybersecurity company founded in Paris in 2017, and our original Good Samaritan Program has warned developers about leaked secrets since day 1. We're the most installed security app on the GitHub Marketplace. Our platform is used by more than 600K developers and by many of the Fortune 500. GitGuardian has completed a SOC 2 Type II audit. Our researchers have been credited by CISA, Oracle, IBM, SAP, and Red Hat. We will never ask for credentials or payment for an alert. If you're unsure whether an alert really came from us, write to security@gitguardian.com.
