Topic starter
24/09/2026 1:27 pm
TL;DR: Secret leakage is still rising, with GitGuardian recording 28.65 million new secrets leaked to public GitHub in 2025 and Wiz finding 65% of Forbes AI 50 companies exposed verified secrets in blind spots scanners often miss, according to Akeyless. Static credentials turn one mistake into a long-lived access problem; the governance answer is prevention plus automatic expiry, not scanning alone.
NHIMG editorial — based on content published by Akeyless: Secret leakage is effectively unavoidable at some rate
By the numbers:
- Wiz found 65% of Forbes AI 50 companies leaked verified secrets in places most scanners don’t check: notebooks, logs, VS Code extensions, and support portals.
- Only 5.7% of organisations have full visibility into their service accounts.
- 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
Questions worth separating out
Q: What breaks when secret scanning is only done before commit?
A: The main break point is enforcement.
Q: Why do API keys and tokens on endpoints increase breach risk so much?
A: Because API keys and tokens act like non-human identities with immediate replay value.
Q: How should teams decide between secret scanning and dynamic secrets?
A: Use secret scanning to detect mistakes faster, but use dynamic secrets when the cost of a leaked credential is high enough that detection alone is not acceptable.
Practitioner guidance
- Block obvious secret entry points Enable pre-commit hooks and repository-level push protection so recognizable credential patterns are stopped before they reach shared branches.
- Expand scanning beyond the repository Add coverage for notebooks, logs, VS Code extensions, support portals, and container layers because those are common blind spots where verified secrets are pasted or echoed outside normal source control.
- Move high-risk credentials to dynamic issuance Replace hardcoded long-lived secrets with short-lived credentials that expire automatically, then map TTL to the actual task duration so leaked copies lose value quickly.
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 repository exclusions.
- The incident containment sequence for rotating exposed credentials and checking downstream dependencies.
- The comparison of scanning, traditional secrets managers, and dynamic secrets in practical deployment terms.
- The Akeyless-specific implementation example showing how dynamic TTL changes the exposure window.
👉 Read Akeyless's analysis of how to prevent secret leakage →
Secret leakage and dynamic secrets: what IAM teams need to change?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
24/09/2026 1:27 pm
Static secret exposure is a lifecycle failure, not a scanning failure. The article is right to separate detection from prevention because the control gap begins when a credential is issued as a durable object with no enforced expiry. OWASP-NHI and lifecycle governance both point to the same problem: if a secret stays valid after it escapes, the attack surface is already baked in. Practitioners should treat every long-lived secret as a standing NHI risk, not a recoverable typo.
A few things that frame the scale:
- 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, which helps explain why exposed credentials often stay live longer than teams expect.
A question worth separating out:
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. The goal is to limit reuse before an attacker can convert exposure into access. Waiting for confirmation usually gives the attacker more time than defenders have.
👉 Read our full editorial: Secret leakage is unavoidable without short-lived NHI controls
