Notifications
Clear all
Topic starter
25/06/2026 5:06 pm
TL;DR: Six 2023 leaks exposed how hardcoded secrets, over-privileged tokens, and stale credentials can reveal internal data, source code, and sensitive government information across AI, containers, open source, and email workflows, according to Entro Security. The pattern is not detection failure alone, but a governance model that still treats secrets as static assets instead of living identities.
NHIMG editorial — based on content published by Entro Security: 6 infamous cybersecurity leaks of 2023
By the numbers:
- Lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations.
Questions worth separating out
Q: How should security teams stop secrets from leaking through code and collaboration tools?
A: Teams should treat code repositories, container registries, package indexes, email, and chat as one continuous secret exposure surface.
Q: Why do leaked secrets create such a large security impact?
A: A leaked secret often carries more privilege than the task actually needs, so one exposed credential can open storage, code, or operational systems at scale.
Q: What do organisations get wrong about secret rotation?
A: They often treat rotation as an occasional cleanup activity instead of a lifecycle control.
Practitioner guidance
- Scan every code commit for embedded secrets Inspect each new commit, branch, and pull request before it reaches public or broadly shared repositories.
- Map secret scope before distribution Review whether a token, SAS key, or service credential grants only the minimum access needed for the task.
- Automate rotation for long-lived credentials Set expiry and replacement windows for secrets that survive beyond a single deployment or project.
What's in the full article
Entro Security's full blog covers the operational detail this post intentionally leaves for the source:
- The specific leak examples and the exact secret types exposed in each case
- The article’s breakdown of how much access some of the leaked credentials actually granted
- The practical examples of repository, container, and package scanning paths
- The defence-sector email case and the long-lived password exposure timeline
👉 Read Entro Security's roundup of six infamous cybersecurity leaks from 2023 →
Secrets leaks in 2023: what IAM and NHI teams missed?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
25/06/2026 5:35 pm
Secrets are still being governed like static text, not identities. The article shows the same failure across code, containers, datasets, and email: a secret is created once and then assumed to remain safe unless someone notices otherwise. That assumption is no longer defensible in NHI programmes, because the exposure surface now includes collaboration systems and AI workflows as well as source control. The practitioner conclusion is simple: if the secret has a lifecycle, it needs identity governance.
A few things that frame the scale:
- From our research: 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
- Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, which shows how far governance lags behind exposure.
A question worth separating out:
Q: Who is accountable when a leaked secret exposes sensitive data?
A: Accountability sits with the programme that issued, stored, shared, and failed to retire the secret, not just with the person who first typed it. IAM, NHI, platform, and application owners all need clear ownership for discovery, rotation, and revocation. Without assigned accountability, exposed credentials persist.
👉 Read our full editorial: Six 2023 secrets leaks show where NHI controls failed
