GitGuardian’s recent State of Secrets Sprawl 2026 report put a hard number on a problem many teams already recognize in smaller ways - that 28.65 million new hardcoded secrets were added to public GitHub commits in 2025, up 34% year over year. GitGuardian also says public GitHub commits climbed to about 1.94 billion in 2025, while the active developer base grew 33%.
Those numbers matter because they help explain why this keeps getting worse even at teams that know better. More code is being written, more services are being wired together, and more credentials are being created for build systems, cloud access, third-party APIs, AI services, internal tooling, and deployment jobs. The leak count rises along with that.
For product teams, this reaches into CI/CD, local configuration, cloud authentication, support handoffs, chat threads, and temporary scripts. That is why a review can start with repository scans, but needs to go beyond that too.
Why The Number Keeps Going Up
Most leaked secrets come from ordinary work under time pressure. A token gets dropped into a config file to get something running locally, a workflow is given a static credential so a deploy can go out, someone copies a value into a shell script and plans to clean it up later, or a quick proof of concept becomes part of the stack. A repo meant for experimentation ends up being used for something real.
GitGuardian’s report describes 2025 as a year when software production accelerated sharply, with more agents, integrations, services, and configuration patterns entering normal development work. That is the backdrop for the increase in exposed credentials.
That pattern also changes the way teams should think about the issue. A lot of companies still treat secrets management as a repository hygiene problem. Sure, that matters, but it is only one layer.
Repositories Are Only Part Of The Surface
One of the more useful findings in the GitGuardian report is that public repositories are only the visible part of the problem. Internal repositories are roughly six times more likely than public repositories to contain hardcoded secrets and about 28% of incidents originate entirely outside repositories - in tools like Slack, Jira, and Confluence. Those non-code incidents were 13 percentage points more likely to be critical than leaks found only in code.
That lines up with how these problems show up in practice. A repository may be reviewed carefully while a rushed chat message isn’t, a ticket written during an outage can end up holding a live token, or a screenshot used to explain a deployment issue can expose something that never appears in the codebase at all.
A secrets review that looks only at source control misses too much. The better question is.. where are credentials moving during normal work?
A Better Review Surface
For most teams, that means looking at four areas together:
- Repositories and commit history
- CI / CD workflows and runners
- Collaboration tools and tickets
- Local config files and developer tooling
That is a broader review than many teams are used to running, but it is closer to where you need to be.
AI Tooling Has Opened New Leak Paths
The AI-related part of the report is worth reading closely because it reflects how fast developer habits changed over the last year.
AI service secrets reached 1,275,105 in 2025, up 81% year over year. Also, eight of the ten fastest growing detectors were tied to AI services, and that LLM infrastructure such as orchestration, retrieval, and vector storage leaked five times faster than core model providers.
They also found 24,008 unique secrets exposed in MCP-related configuration files across public GitHub, including 2,117 unique valid credentials. The report points to setup patterns that encourage developers to place API keys directly into config files, command-line arguments, or connection strings.
That creates a very specific kind of cleanup problem. Teams are not only dealing with exposed secrets in code, but also dealing with copied setup patterns that normalize weak credential handling from the start.
CI/CD Needs Its Own Review
Automation is often treated as trusted plumbing. 59% of compromised machines in the Shai-Hulud 2 dataset analyzed were CI/CD runners rather than personal workstations. That is a useful reminder that workflow systems are credential holders with real access.
And GitHub’s own documentation points in the same direction.
They say OpenID Connect lets Actions workflows access cloud resources without having to store credentials as long-lived GitHub secrets. It also says teams should define at least one condition so untrusted repositories cannot request access tokens for cloud resources.
GitHub’s secure use reference also says there is significant risk in sourcing actions from third-party repositories, since a compromised action can access repository secrets and may be able to use GITHUB_TOKEN to write to the repository. Its guidance is clear - pin actions to a full-length commit SHA. That is currently the only way to use an action as an immutable release.
Three Workflow Checks
If your team wants a short list to start with, these three are worth reviewing early:
- Replace long-lived cloud credentials in Actions where OIDC is available
- Check whether third-party actions are pinned to full commit SHAs
- Put stricter review around changes to workflow files, including CODEOWNERS for workflow directories.
- GitHub recommends CODEOWNERS so workflow changes require approval from designated reviewers.
These changes may reduce the number of static credentials sitting in the workflow layer.
Need Help Untangling Secrets Across Repos, CI/CD, and AI Tooling?
If credentials are spread across older workflows, deployment scripts, integrations, or local AI tooling, we can help you review the exposure and clean it up without breaking your systems.
What Should You Review This Week?
1. Repository History
Review:
- Older commits
- Archived repositories
- Demo projects
- Sample code
- Utility scripts
- Environment files that may have been committed only once
2. Workflow Secrets & Cloud Access
Review:
- Repository secrets
- Organization secrets
- Static cloud credentials
- Deploy keys
- Service account usage in CI/CD
If OIDC fits the environment, it is worth a serious look because it removes some long-lived credentials from the workflow entirely.
3. Third-Party Actions
Check whether actions are pinned to full commit SHAs or still following mutable tags and branches. GitHub’s guidance on this is straightforward.
4. Collaboration Tools
Review:
- Tickets
- Chat threads
- Incident notes
- Screenshots
- Pasted logs
- Internal documentation
This is one of the easiest places for secrets to appear because it sits outside normal code review.
5. AI-Related Configs
Look at:
- MCP config files
- Agent configs
- Wrappers
- Demo environments
6. Remediation Ownership
For every live credential, someone on your team should be able to answer:
- Who owns it
- Where it is used
- What it can access
- How it is rotated
- What breaks if it is revoked
What Usually Slows Down Cleanup
Detection is only part of the problem. GitGuardian says that when it retested credentials confirmed as valid in 2022, more than 64% were still valid in January 2026. It also says 46% of critical secrets are missed by validation-only prioritization.
Teams can often find exposed credentials faster than they can unwind them. Once a leaked key is tied to an older deployment script, a brittle integration, or an internal admin tool that nobody wants to touch, the issue starts looking like platform maintenance.
That is one reason this work often lands closer to infrastructure and integration cleanup than to a one off security fix. When credentials are spread across applications, services, workflows, and hand-built deployment logic, the problem usually sits in the same space as custom APIs and integrations.
A Useful Way To Frame The Problem
One of the reasons this topic is easy to underestimate is that ‘secret leak’ still sounds like a coding mistake. In practice, the problem is wider than that, including:
- Where credentials are created
- Where they are copied
- How long they live
- How they are used in workflows
- Whether anyone owns them clearly
- How quickly they can be rotated without breaking something else
That is why a basic scan is helpful, but not enough. The harder work usually starts after the first detection report comes in.
Where To Start If The Backlog Is Already Messy
If the current state is already hard to untangle, start with the places most likely to hold broad access:
- Production cloud credentials
- CI/CD secrets
- Service accounts with cross-system access
- AI-provider and infrastructure keys
- Credentials exposed in chat, tickets, or docs
That order is a judgment call, not a universal rule, but it usually gives teams a more practical starting point than trying to clear every alert in chronological order.
In closing, GitGuardian’s report is useful because it puts scale behind a pattern that many teams already see up close. The GitHub guidance is useful because it shows where some of the practical controls already exist: OIDC, tighter workflow review, immutable action pinning, etc.
A good review now should go further than source control - repositories obviously still matter, but so do workflows, runners, AI configs, support notes, shared documentation, and old credentials.
