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.
Editorial analysis by NHI Mgmt Group, based on content published by Xygeni: “Best Secrets Management Tools (2026): Vaults & Scanners Compared”.
By the numbers:
- AI-related secrets surged 81% year over year, reaching over 1.27 million leaked credentials.
- 64% of credentials confirmed valid in 2022 were still exploitable as of January 2026, four years after first being exposed.
Key questions
Q: What breaks when a secret is deleted from code but not revoked?
A: The exposure remains active because repository cleanup does not remove standing privilege.
Q: Why do leaked API keys and tokens create such a large security risk?
A: They authenticate actions directly, so anyone who finds them can act as a trusted caller.
Q: What are the signs that a secrets management programme is failing?
A: Common warning signs include inconsistent secret formats, missing scans in configuration files or side repositories, frequent false positives, and teams relying on manual checks instead of automation.
Practitioner guidance
- Block hardcoded secrets before merge Enforce repository and pull request policy that fails builds when API keys, tokens, passwords, or certificates are detected in code or configuration.
- Automate revocation on confirmed exposure Connect secret detection to response workflows that revoke compromised credentials as soon as a finding is validated, rather than waiting for manual triage.
- Separate detection from lifecycle control Use scanning to find leaks, but make rotation, replacement, and ownership transfer mandatory follow-on steps for every confirmed secret exposure.
Bottom line: Hardcoded secrets are now a high-frequency access problem, not just a coding mistake, because exposed credentials can immediately unlock cloud and pipeline resources.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
20/08/2026 6:31 pm
Secrets sprawl is now an access-lifecycle failure, not a detection problem: The article shows that visibility without invalidation leaves credentials exploitable long after discovery. That means the governing question is no longer whether a secret was found, but whether its privilege has been removed from circulation. The implication is that secrets governance must be judged by revocation velocity, not scan volume.
A few things that frame the scale:
- 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded, according to the State of Secrets Sprawl 2026.
- Only 44% of organisations are currently using a dedicated secrets management system, according to the 2024 State of Secrets Management Survey.
A question worth separating out:
Q: How should security teams handle secrets found in collaboration tools and MCP configs?
A: Treat them the same way you would treat a leaked repository secret: assume they are active until proven otherwise, then revoke or replace them through a governed workflow. Collaboration platforms and MCP configs can expose credentials outside traditional code scanning, so the inventory and response process has to include those locations explicitly.
👉 Read our full editorial: Secrets sprawl in 2026: why detection alone is failing