TL;DR

• A credential leak far beyond company walls: 28.65 million new hardcoded secrets in public GitHub commits in 2025 (up 34%), and almost 80% of one customer's corporate leaks traced back to developers' personal repositories, a risk echoed by the CISA leak found in May 2026.
• New verdicts cut through the noise: GitGuardian's Agents Analysis now cleanly labels each public incident, reorganizing the Public Monitoring queue around company relevance so analysts start where the risk actually is. It is available now for all customers.
• Reasoning and feedback close the loop: A new Analysis tab shows exactly why an incident got its verdict, and analysts can thumbs up or down each call, helping GitGuardian sharpen company attribution as Agents Analysis becomes the default experience.

Your credential layer extends much farther than the systems your company owns.

Credentials move through company repositories, developer environments, and CI/CD systems. Some eventually cross into places your organization and security team do not control. That crossing point is a credential leak, and it doesn't wait for your team to notice it.

Public GitHub gives us a very clear picture of how often this happens.

GitGuardian detected 28.65 million new hardcoded secrets in public GitHub commits in 2025, up 34% from the previous year. About 5.6% of public repositories contained at least one secret, according to the State of Secrets Sprawl 2026.

GitHub itself has independently reported tens of millions of secret leaks across its platform. Different methodologies produce different totals, but the direction is clear. Credentials continue to escape into public development activity at enormous scale.

For a security team, finding secrets across that public surface creates another hard set of problems: "Which of those credentials are actually yours and which ones require action?"

Ever since GitGuardian was founded, we have been helping customers answer exactly that question with the platform's Public Monitoring capabilities.

Our latest update gives security, DevSecOps, and developer teams a much clearer, consistent, and actionable answer.

Your public credential exposure extends beyond the repositories you own

GitGuardian has scanned every commit that has been pushed to public GitHub repositories since 2017, as well as all private commits that became public. That visibility powers our Good Samaritan program, where we alert developers after detecting compromised credentials they accidentally exposed.

GitGuardian customers using the Public Monitoring capacity gain access to the same massive public dataset to identify exposures associated with their organization. Every public GitHub commit is scanned in real time, alongside historical scanning designed to uncover earlier exposures.

One former CISO explained why this visibility was so important after her team expanded its view beyond the repositories they controlled.

"What was very interesting and what we didn't anticipate was that most of the alerts came from the personal code repositories of our developers." - Anne Hardy, Talend

Our case study with Talend found that almost 80% of corporate credential leaks detected on GitHub occurred in developers' personal repositories. They knew this was such a serious issue that the team had even attempted to build its own solution. Personal repositories remained a major blind spot.

The CISA GitHub leak shows what that blind spot can look like

We got another very concrete reminder of this in May 2026. GitGuardian found a public GitHub repository named Private-CISA containing 844 MB of data connected to CISA. Some of the leaked credentials were still valid.

The repository included plaintext passwords and AWS tokens. It also contained Entra ID SAML certificates. There was plenty of operational context around those credentials too. CI/CD logs and Kubernetes configuration exposed details about how systems were deployed. Terraform code and internal documentation provided even more information about the environment.

Developers work across corporate and personal environments. They contribute to open source projects and experiment in their own repositories. Credentials can travel with that work. The repository might belong to the developer, but the credential can still grant the company access.

That is exactly the kind of visibility Public Monitoring was built to provide.

What is public secrets monitoring

Public secrets monitoring watches public development activity for compromised credentials connected to an organization.

GitGuardian Public Secrets Monitoring builds a company public perimeter using developers and GitHub organizations. Company-specific secret graspers add another layer of context. This lets us identify exposures in repositories the company does not administratively control.

The scale makes context essential.

A public repository might contain a perfectly real AWS credential that has nothing to do with your organization. Another repository might belong to someone you have never heard of while containing a credential surrounded by strong signals pointing back to your infrastructure.

Both are secrets. Only one might be yours.

Once a credential becomes public, the identity and permissions behind it determine the real risk.

Finding the secret is easier than deciding whether it belongs to you

Public Monitoring has always had to solve two problems.

First, detect secrets across an enormous public surface. This is rather straightforward to solve and is what drives our work on our secrets detection engine. 

The second issue is determining which incidents deserve the attention of a particular company. This gets difficult rather quickly. A cloud credential appears in a developer's personal repository. The developer works for your company, but the credential could belong to a personal cloud account.

Another credential appears in a third-party repository. The repository has no obvious ownership connection to your company, but the surrounding context points to one of your internal services. This was the case with the CISA contractor who used a Yahoo email address.

Simple rules can provide useful clues, but at scale, they leave analysts with a lot of investigative work.

The new Agents Analysis experience makes GitGuardian's company-relevance analysis much easier to understand and use directly from the Public Monitoring workflow.

Company-related verdicts answer the question analysts actually have

Agents Analysis is enabled automatically for GitGuardian customers utilizing the public monitoring capability. All analyzed public incidents receive a Company-related verdict:

• A Related verdict means the analysis concluded that the leak belongs to your company.
• An Uncertain verdict means the available evidence could not support a definitive conclusion.
• An Unrelated verdict means the analysis concluded that the incident does not belong to your organization.
• Incidents awaiting analysis remain empty. Only deep analysis can positively confirm an incident as Related.

This gives analysts a much clearer place to begin.

The UX now reflects the question security teams actually need answered: "Does the available evidence indicate that this leaked credential belongs to us?"

The incident list now starts with relevance

The Public Monitoring incident list has also been reorganized around company relevance.

Users now see three new saved views alongside "All" and "Open."

• Company-related collects incidents that the analysis connects to the organization.
• Unclear if company-related gives analysts a focused queue for ambiguous cases.
• Not company-related separates incidents that do not belong in the remediation workflow.

The Company-related and Risk score columns also appear by default. 

This creates a much cleaner workflow.

Public Monitoring starts with an enormous public dataset. Every irrelevant incident consumes investigation time.

Repeatedly pulling a developer into an investigation that turns out to have nothing to do with the company also erodes confidence in the process.

Relevance needs to be visible from the moment an analyst opens the queue.

Agent risk scores bring the real credential exposure toward the top

The release of the new Agents Analysis also marks a meaningful evolution in how public incidents are scored. The agent-generated score now accounts for how strongly the incident appears connected to the company, rather than a risk score focused primarily on the secret's characteristics and its exposure. 

An incident determined to be Unrelated receives a score of zero. For example, if the platform can determine this was a test credential for an open-source project the developer contributes to, there should be no action needed, just an informational tag added.  Any incident awaiting analysis has no score yet, further reducing the number of alerts that require no attention.

A public leak can stay dangerous long after everyone has forgotten the workflow that produced it. 

Prioritization based on your connection to your org becomes even more valuable when legacy credentials remain active for years. Our State of Secrets Sprawl 2026 revisited valid credentials originally found in 2022. Sixty-four percent were still active and exploitable in January 2026.

The Analysis tab exposes the reasoning behind the verdict

The biggest improvement in this release is the new Analysis tab.

Customers can now open an incident and see how GitGuardian reached its conclusion.

The tab shows the identified company and Company-related verdict. It also provides the reasoning behind that verdict.  The Investigation details section shows how the incident moved through triage and deeper analysis when needed.

This gives analysts evidence they can inspect. The analysis might identify a connection with a known developer. It might find company-specific information near the credential. Several signals can combine into a strong case for ownership.

The analyst can compare those findings with their own knowledge and decide what to do next.

Public Monitoring has been doing the difficult work of finding relationships across public exposure for years. The new UI makes much more of that work visible.

Users can tell us when the analysis needs to improve

The Analysis tab now includes feedback controls too.

Users, for the first time, can give the result a thumbs up or thumbs down and optionally leave a comment. This will help us improve results over time and eliminate false positives faster. 

Company attribution is a hard problem because every organization leaves a different trail across development infrastructure. Feedback gives us direct evidence about where the agents are getting the analysis right and where they need to improve.

If an incident is clearly yours and the analysis catches it, please tell us. If the analysis gets the relationship wrong, tell us that too.

Public Monitoring is part of a much larger credential layer problem

Public GitHub is only one place where credentials surface. The larger credential layer starts much earlier.

Plaintext credentials can spread through private repositories, local .env files, and internal ticketing systems. Those locations often feel controlled enough that teams tolerate secrets living there longer than they should.

Our data showed that 28% of secrets incidents occur entirely outside code repositories, including collaboration and productivity systems. Only 4% appear in both code repositories and those other sources.

Over time, copies accumulate. A developer can move code into a new repository. Someone can copy configuration into a support thread. A credential that once lived in an internal environment eventually appears somewhere in a public repo.

A public incident can therefore reveal credential sprawl that already existed elsewhere in the organization.

This is why GitGuardian frames the broader problem as credential layer security. We recently explored the same problem in more detail by following how credentials slip through the gaps between security tools.

Public Monitoring extends visibility into public sources where credentials can appear after crossing organizational boundaries. Coverage currently includes public GitHub commits and historical Gists, with additional public sources such as Docker Hub expanding that perimeter.

The goal is a clearer picture of where credentials exist and where they travel.

Public Monitoring shows you the part of that credential layer that has crossed beyond your borders.

Agents Analysis is becoming the default Public Monitoring experience

Agents Analysis is now enabled by default for new Public Monitoring workspaces.

New users immediately get the Company-related verdict, agent risk score, Analysis tab, and new saved views.

Existing customer workspaces are being rolled over more gradually because Agents Analysis remains in beta and has not yet been enabled in every dashboard.

We recognize many existing customers already have workflows built around the previous tags and scoring. We want teams to understand how the updated analysis affects those workflows before changing the experience underneath them. 

Customers who want to try the experience can work with their Customer Success Manager or contacts at GitGuardian.

Go find out how far your credential layer really extends

Public Monitoring gives you a useful place to start examining your true credential exposure.

We would be happy to show you the credentials GitGuardian believes belong to your organization and let you inspect the Analysis tab and inspect the evidence.

You should be asking how much of your credential layer exists outside the systems your security team currently controls.

The GitGuardian platform can give you visibility into your part of that problem.