Notifications
Clear all
Topic starter
20/08/2026 5:52 pm
TL;DR: GitGuardian’s 2026 analysis, cited by Xygeni, shows 28.65 million new hardcoded secrets in public GitHub commits in 2025, a 34% rise, while AI-related credential leaks surged 81% and 64% of valid secrets from 2022 were still exploitable in 2026, underscoring a remediation gap. Detection alone is no longer enough; lifecycle control and revocation now determine exposure.
NHIMG editorial — based on content published by Xygeni: Secrets management tools comparison for 2026
By the numbers:
- Claude Code-assisted commits showed a 3.2% secret-leak rate, versus a 1.5% baseline across all public GitHub commits.
- AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers.
Questions worth separating out
Q: How should security teams respond when leaked credentials may still be valid?
A: Security teams should assume the credentials are active until proven otherwise.
Q: Why do secrets keep reappearing even when organisations already scan for leaks?
A: Because scanning only finds exposure after the fact, while the underlying creation habits remain in place.
Q: Where should teams look first when secrets incidents are not coming from repositories?
A: Start with collaboration platforms, ticketing systems, build logs, and configuration files.
Practitioner guidance
- Implement detection plus revocation workflows Do not stop at finding secrets in repositories or CI logs.
- Expand scanning beyond source control Include Slack, Jira, Confluence, build artifacts, and configuration files in the same secrets policy because the article shows leaks frequently originate outside code.
- Add stricter controls to AI-assisted commit paths Flag commits produced with AI coding tools for enhanced review, pre-commit secret checks, and branch protection.
What's in the full article
Xygeni's full guide covers the operational detail this post intentionally leaves for the source:
- Side-by-side feature comparison of secret scanners, vaults, and guardrail platforms across repos, PRs, containers, and pipelines
- Pricing and deployment notes for AWS Secrets Manager, HashiCorp Vault, Infisical, Doppler, GitGuardian, and other tools
- Workflow guidance for validation, blocking, and auto-remediation when a leak is found in CI/CD or Git history
- Tool-by-tool coverage of integrations with GitHub, GitLab, Bitbucket, Azure Repos, Kubernetes, and cloud SDKs
👉 Read Xygeni's 2026 guide to secrets management tools and secret sprawl →
Secrets sprawl in 2026: are your controls keeping up?
Explore further
20/08/2026 6:31 pm
Secrets sprawl is now a lifecycle failure, not a detection problem. The article's data shows that valid secrets can remain exploitable years after exposure, which means discovery without revocation leaves the identity alive. This is the central governance failure mode for NHI programmes: visibility has outpaced lifecycle control. Practitioners should treat exposed credentials as active identities until proven otherwise.
A few things that frame the scale:
- 64% of secrets confirmed valid in 2022 were still exploitable as of January 2026, four years after first being exposed, according to The State of Secrets Sprawl 2026.
- 28% of secrets incidents now originate outside code repositories, in Slack, Jira, and Confluence, and they are 13% more likely to be classified as critical than code-based leaks.
A question worth separating out:
Q: What is the difference between secret scanning and secrets management?
A: Secret scanning finds credentials that have been exposed, while secrets management controls how credentials are stored, issued, rotated, and revoked. Scanning is detective. Management is preventive and lifecycle-based. Strong programmes need both because discovery alone does not remove access.
👉 Read our full editorial: Secrets sprawl in 2026: why detection alone is failing
