Topic starter
25/06/2026 5:08 pm
TL;DR: Neho’s exposed .env file left AWS credentials, API keys, and email service secrets accessible, creating phishing, code-signing, and cloud abuse risk, according to Entro Security. The incident shows that secrets management fails when discovery, rotation, and access control are treated as separate tasks instead of one governance chain.
Editorial analysis by NHI Mgmt Group, based on content published by Entro Security: “The tale of Neho’s misplaced keys and unwanted open houses”.
Key questions
Q: What breaks when a .env file exposes live cloud secrets?
A: A single exposed .env file can collapse several controls at once because it often contains database passwords, API keys, and email service credentials.
Q: Why do exposed service account credentials create such broad risk?
A: Service account credentials often carry standing access into cloud, CI/CD, or SaaS systems, so one exposed secret can open multiple control paths at once.
Q: How can teams tell whether secret rotation is actually reducing risk?
A: Teams should look at whether a rotated secret was ever exposed at runtime, whether it still works in downstream systems, and how quickly it can be revoked everywhere it matters.
Practitioner guidance
- Audit exposed configuration paths Search public web roots, repositories, CI artifacts, and shared storage for credential-bearing files such as .env, then remove any file that contains live secrets.
- Classify each secret by service reach Document whether a credential can access databases, email delivery, cloud APIs, or third-party tools so the team can see the real blast radius of each secret.
- Enforce owner-linked rotation Require a named owner to confirm usage before rotating a secret, then revoke credentials that no longer map to an active service or approved integration.
Bottom line: The Neho incident shows how exposed environment files can turn routine cloud configuration into a multi-service identity problem.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 1 day ago by NHI Mgmt Group
25/06/2026 5:39 pm
Secrets governance failed because discovery, ownership, and revocation were treated as separate controls. The Neho case is not about a single leaked file so much as a broken lifecycle chain. Once a secret can be discovered in one place, copied into another, and left active after its original purpose changes, the programme no longer has a coherent control boundary. The implication is that secrets management must be governed as one end-to-end identity process, not as a collection of disconnected tasks.
A question worth separating out:
Q: Should IAM teams treat application secrets like machine identities?
A: Yes. Application secrets behave like machine identities because they authenticate systems, not people, and they need lifecycle governance just like any other non-human identity. IAM teams should apply inventory, access scope review, rotation, and offboarding discipline to those secrets instead of leaving them in ad hoc application ownership.
👉 Read our full editorial: Neho’s exposed secrets show how weak NHI governance fails
This post was modified 1 day ago by NHI Mgmt Group