Topic starter
24/09/2026 1:27 pm
TL;DR: Akeyless cites GitGuardian’s 28.65 million new secrets leaked to public GitHub in 2025 and Wiz’s finding that 65% of Forbes AI 50 companies exposed verified secrets in places scanners often miss. Static credentials turn one mistake into a long-lived access problem; prevention and automatic expiry matter more than scanning alone.
Editorial analysis by NHI Mgmt Group, based on content published by Akeyless: “Secret Leakage Is Inevitable, but Breaches Don’t Have to Be”.
By the numbers:
- 65% of Forbes AI 50 companies leaked verified secrets in places most scanners don't check, according to Akeyless.
Key questions
Q: What should teams do when a secret may already be exposed?
A: They should assume the secret is compromised until proven otherwise, revoke it, rotate dependent credentials, and check for secondary copies across repositories, tickets, and collaboration tools.
Q: Why do static credentials create more risk than short-lived access tokens?
A: Static credentials create more risk because they remain valid until someone finds and removes them, which gives attackers a durable entry path.
Q: What are the signs that secret scanning is failing to find leaks?
A: The main signals are leaks appearing in notebooks, logs, support portals, and other systems outside source control, plus secrets that remain valid long after discovery.
Practitioner guidance
- Block secrets before commit Use pre-commit hooks and repository-level push protection so recognizable credential patterns never reach shared branches or public repos.
- Extend detection beyond repositories Scan logs, notebooks, support portals, build artifacts, and container layers, because those are common leak paths that standard repo scans miss.
- Replace static credentials with expiring ones Issue dynamic secrets with short TTLs for workloads, automation, and privileged integrations so leaked copies stop being useful quickly.
Bottom line: Secret leakage is best treated as a lifecycle and exposure-window problem, not just a detection problem.
What's in the full article
Akeyless's full article covers the operational detail this post intentionally leaves for the source:
- The step-by-step prevention checklist for pre-commit hooks, push protection, and .gitignore hygiene
- The incident-response sequence for rotating a confirmed leak and checking downstream usage
- The comparison of secret scanning, traditional secrets managers, and dynamic ephemeral secrets
- The case examples showing how long-lived credentials remained exploitable in real incidents
👉 Read Akeyless's analysis of secret leakage and short-lived NHI controls →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
24/09/2026 1:27 pm
Secret leakage is a governance problem, not a scanning problem. The dominant failure is not that organisations lack tools to detect exposed credentials, but that they continue issuing credentials whose usefulness survives the leak itself. When a secret remains valid for months, detection becomes a cleanup function rather than a control boundary. The practical conclusion is that NHI governance has to reduce the value of the leaked credential, not just improve the odds of finding it.
A question worth separating out:
Q: Should organisations prioritise push protection or dynamic secrets first?
A: If secrets are still being committed to source control, push protection is the first containment step because it stops obvious leaks at the point of entry. If static credentials are already widespread, dynamic secrets become the higher-value next move because they remove the long-lived access problem that scanning cannot solve.
👉 Read our full editorial: Secret leakage is unavoidable without short-lived NHI controls