Nearly 29 million secrets leaked into public GitHub commits in 2025, a 34% jump in newly detected credentials over the year before. According to GitGuardian’s State of Secrets Sprawl 2026 report, that growth isn’t spread evenly: AI-assisted commits leak secrets at roughly twice the baseline rate, and internal repositories – the ones teams assume are safe because nobody outside the company can see them – are six times more likely to contain a hardcoded credential than public ones. Secrets sprawl stopped being a public-GitHub problem years ago. It now lives mostly inside the CI/CD systems teams depend on to ship code every day, which is exactly where a leaked credential does the most damage the fastest.

The uncomfortable part of secrets sprawl isn’t that credentials leak – it’s how long they stay exploitable once they do. Teams scan, find a hardcoded secret, and then leave it alone because rotating a production credential feels riskier than the leak itself. That instinct is understandable, and it’s also exactly how that exposure compounds year over year instead of shrinking, quietly outpacing whatever scanning coverage a team already has in place. The six patterns below aren’t a shopping list of tools. They’re the operational habits that separate teams whose pipelines quietly accumulate secrets sprawl from teams that actually close the gap once a credential gets out.

Secrets sprawl is compounding faster than review cycles can catch it

The scale of today’s secrets sprawl isn’t just a bigger version of an old problem – it’s a different shape of problem. GitGuardian’s research tracked 28,649,024 new secrets exposed on public GitHub in 2025 alone, continuing a run that has pushed leaked-secret volume up 152% since 2021, roughly 1.6 times faster than the developer population itself grew over the same stretch.

Public GitHub is also renewing quickly: 54% of active developers made their first commit in 2025, which means a large and growing share of the code reaching production every day comes from teams and tooling that haven’t built secrets hygiene into muscle memory yet. Fyld’s own IT Team Expansion engagements exist partly to close that exact gap – pairing a fast-scaling engineering org with people who already carry that muscle memory, instead of leaving a growing team to learn secrets hygiene the hard way, mid-incident.

AI-assisted commits leak secrets at close to twice the baseline rate

Commits co-authored by AI coding assistants leak credentials at around two times the rate of ordinary commits across public GitHub, and the volume of AI-assisted commits itself grew from roughly 1,300 a month in late 2024 to well over three million a month by late 2025. Faster code production without a matching increase in review scrutiny is precisely the condition under which secrets sprawl accelerates, and it’s compounding at the same moment AI-assisted development is becoming the default rather than the exception.

Internal repositories carry more of the risk than the public ones everyone worries about

32.2% of internal repositories contain at least one secret, compared with 5.6% of public repositories – a sixfold gap that inverts most teams’ intuition about where the danger sits. Internal repos feel safe because access is restricted to employees, but restricted access isn’t the same as reviewed access, and it’s exactly the assumption that lets exposed credentials accumulate quietly behind a company’s own firewall for years at a time, often outliving the project or the team that created them.

A committed secret rarely gets rotated once the code review closes

Detection was never really the hard part of secrets sprawl. Remediation is. Among secrets found valid in 2022, 64% were still active and exploitable four years later, sitting untouched in the same repositories where they were first discovered — and long-lived secrets that are simply never rotated account for 60% of all policy violations tracked, more than every other category of failure combined.

Most of those credentials aren’t tied to a person who could get a Slack message asking them to rotate a password. They’re service accounts, API keys, and machine-to-machine tokens that nobody owns in the way a human owns their own login, which is a big part of why Fyld’s own research into Non-Human Identity: 5 Gaps AI Agents Expose in IAM  treats these credentials as their own governance category rather than an afterthought bolted onto human account management.

Long-lived secrets are still the single biggest category of failure

A secret that never expires is a secret that never has to be defended against a changing threat model. Teams that can point to an actual rotation cadence – not “we could rotate it if we needed to,” but a scheduled, enforced process – are the exception rather than the rule, and it shows in how much of the secrets sprawl problem traces back to credentials that have simply never been touched since the day they were created.

Platform-level guardrails now close gaps manual rotation never did

Registries are starting to build the enforcement in rather than leaving it to individual teams. As of July 2026, npm tokens configured to bypass two-factor authentication can no longer perform sensitive account and package management actions without an interactive 2FA challenge, closing off a pattern where a single leaked bypass token could mint new tokens and add maintainers without ever triggering a human-facing prompt. That’s the direction secrets sprawl remediation needs to move in generally: guardrails a leaked credential can’t talk its way around, rather than a policy document asking people to rotate things they’ll never get around to.

One leaked token can turn into a self-propagating supply chain attack

The clearest illustration of what secrets sprawl actually costs is the Shai-Hulud npm worm. Once installed, the malware used the TruffleHog secret-scanning tool to harvest credentials from the local environment, then validated any GitHub tokens it found and used them to publish malicious versions of every package the token had access to – spreading itself automatically to the next victim’s environment without any further attacker involvement. It was, by Wiz’s own assessment, one of the most severe JavaScript supply-chain attacks observed to date, and it worked entirely by chaining together credential exposure that already existed in developer environments before the attack began, rather thaNn by exploiting any new vulnerability in npm itself.

The second wave of that campaign made the CI/CD angle explicit. Analysis of compromised machines found that 44% held more than ten exposed secrets each, and 5% held over a hundred – but the more telling number is that 59% of the compromised machines were CI/CD runners rather than personal developer workstations.

That reframes secrets sprawl as an infrastructure problem, not just a developer-hygiene one, and it’s the same reframing behind how Fyld structures its DevSecOps Pipeline work as a system of enforced guarantees rather than a sequence of tools bolted onto an existing build process. For teams that need that kind of pipeline discipline built in from day one rather than retrofitted after an incident, Nearshore Software Development pairs Portugal-based delivery teams with exactly that operational standard.

The worm spreads by harvesting whatever tokens it finds in the environment

Shai-Hulud’s self-propagation depended entirely on secrets sprawl already being present: it needed npm tokens in the environment to publish new malicious packages, and GitHub tokens to exfiltrate data and force private repositories public. Without live credentials sitting in reach, the worm would have infected one package and stopped there instead of cascading across the ecosystem.

Most machines compromised in the second wave were CI/CD runners, not laptops

A build runner typically holds credentials for every system it touches – source control, package registries, deployment targets, cloud infrastructure – concentrated in one place and often running with far broader scope than any individual developer’s laptop. That concentration is exactly why CI/CD runners made such an efficient target, and why secrets sprawl inside build infrastructure carries more blast radius per leaked credential than the same sprawl on a single workstation.

Trust relationships, not just vulnerabilities, are what attackers exploit at scale

Regulators and researchers are converging on the same finding from different directions: the attack surface that matters most isn’t a company’s own perimeter anymore. Wiz’s analysis of the 2026 Verizon Data Breach Investigations Report found that third-party involvement in breaches rose from 30% to 48% year over year, driven by attackers abusing trusted relationships – compromised packages, stolen GitHub personal access tokens, CI/CD compromise, and SaaS integrations – rather than breaking through a front door directly.

Vulnerability exploitation is now the single leading initial access vector at 31% of breaches, and the same report found that organizations are losing ground on remediation speed, with the median time to close a known exploited vulnerability climbing from 32 days to 43 in a single year while the number of vulnerabilities requiring attention rose by roughly half.

Third-party involvement in breaches nearly doubled in a year

A jump from 30% to 48% in a single reporting cycle isn’t noise – it’s a structural shift in how attackers are getting in. CI/CD pipelines sit at the center of that shift because they are, by design, one of the most trusted relationships a codebase has: a pipeline runs with the credentials needed to build, test, and ship, and secrets sprawl inside that pipeline hands an attacker exactly the trust relationship the rest of the breach data says is being exploited most.

Remediation is losing ground to the pace of exposure

Only 26% of known exploited vulnerabilities were fully remediated in the period Wiz analyzed, and 16% were left completely unaddressed. Secrets sprawl follows the same pattern for a simpler reason: finding a leaked credential is a solved problem for most teams now, but deciding what to do about it, and actually doing it before something goes wrong, still isn’t.

Least-privilege pipelines close the door standing secrets leave open

If a secret can’t reach very far, a leaked secret doesn’t cost very much. That’s the logic behind GitHub’s workflow execution protections, which reached public preview in June 2026 and let administrators define exactly who can trigger a workflow and which events are allowed to run it, rather than trusting every contributor with write access to run arbitrary CI/CD jobs by default.

The feature is explicitly designed to stop patterns like poisoned pipeline execution from pull requests and manual-trigger abuse through “workflow_dispatch” – both of which are ways attackers turn ordinary CI/CD permissions into a path toward the exact secrets sprawl a pipeline was supposed to protect. That same principle – narrowing who and what can act, rather than trusting broadly and hoping nothing goes wrong – is the foundation Fyld builds on with clients working through Zero Trust Architecture, and it’s the same standard teams get when they bring in Team-as-a-Service engineers rather than layering contractors onto a pipeline that already trusts too many people by default.

Workflow execution protections stop pipelines from running for the wrong trigger

Before this kind of control existed, a workflow ran based purely on whatever was in the workflow file at the time a trigger fired, which meant an attacker with repository access could modify that file and have it execute automatically. Rules that evaluate before a run starts close that gap without requiring every team to reason about CI/CD security one YAML file at a time.

That matters directly for secrets sprawl, since a modified trigger is one of the more common ways a pipeline’s stored credentials end up leaving the environment in the first place — not through a misconfigured scanner, but through a workflow doing exactly what an attacker told it to do.

Named rules replace blanket trust for every contributor with write access

By default, anyone with write access to a repository can trigger its workflows, which quietly extends CI/CD trust – and exposure to whatever secrets sprawl already exists in that pipeline – to every contributor rather than the smaller set of people who actually need it. Separating who can write code from who can execute CI/CD jobs shrinks that exposure without slowing legitimate work down. It’s a narrow change to make, but it removes one of the more common paths a leaked or misused credential takes to become an active secrets sprawl incident rather than a contained one.

Fixing secrets sprawl means governing the pipeline, not scanning it harder

Scanning tools find secrets faster than most teams can remediate them, and that gap keeps widening because the underlying problem isn’t detection. Wiz’s State of SDLC Security 2026 research found that risk in modern software delivery concentrates in a relatively small set of widely reused dependencies, CI/CD actions, and automation components rather than spreading evenly across an organization’s systems, and that developer environments themselves have become a concentrated point of privilege and trust, with roughly 86% of observed developer machines running the same operating system.

That kind of concentration is precisely what turns an ordinary instance of secrets sprawl into a systemic one: a weakness in a single widely reused workflow component doesn’t stay contained to one team, it propagates to every pipeline that depends on it.

Fixing that requires treating the pipeline as a system with enforced guarantees, the same principle behind Fyld’s Container Security work protecting what actually runs once a build finishes. The same discipline applies on the build side too — testing, rollback, and GitOps practices that keep a pipeline predictable are what stop secrets sprawl from becoming the next problem once everything else is locked down.For engineering teams that would rather have that discipline maintained for them long-term than rebuild it internally, IT Managed Services covers exactly that kind of ongoing pipeline governance.

Risk concentrates in the automation systems that connect everything else

CI/CD systems combine execution and automation in a way that turns a single compromised component into an immediate path from development access to production impact. A relatively small set of actions and workflow templates dominates most CI/CD environments, which means fixing secrets sprawl in the handful of components everyone depends on delivers far more risk reduction than scanning every repository with equal priority.

Governance closes the loop that another scanner can’t

Detection tools are necessary but not sufficient. What actually reduces secrets sprawl over time is ownership: a named person or team accountable for what happens after a secret is found, a rotation schedule that gets followed rather than deferred, and pipeline permissions narrow enough that a single leaked credential can’t reach everything a build touches.

What this means for hardening your pipelines

None of the six patterns above require a bigger security budget before you can start. They require treating secrets sprawl as an operational discipline that lives inside the pipeline itself, rather than a periodic scanning exercise that happens alongside it. A credential that’s short-lived, scoped to exactly what it needs, and owned by someone who’s accountable for rotating it closes more of the gap than any single tool added on top of an already-sprawling set of long-lived secrets.

If your team is weighing how much of that discipline to build in-house versus bring in, that’s exactly the kind of gap Fyld works alongside engineering teams to close, from pipeline architecture through the day-to-day discipline that keeps secrets sprawl from creeping back in once the initial cleanup is done. Get in touch with Fyld to talk through what that looks like for your pipelines.