Notifications
Clear all
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.
NHIMG editorial — based on content published by Entro Security covering the Neho secrets exposure incident: The tale of Neho’s misplaced keys and unwanted open houses
By the numbers:
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
- 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.
Questions worth separating out
Q: How should security teams handle exposed API keys and service credentials?
A: Treat exposed credentials as active identities, not as misplaced text.
Q: Why do service accounts and API keys increase breach impact so quickly?
A: Because they usually carry persistent, reusable access across multiple systems.
Q: What do teams get wrong about secrets rotation?
A: They often treat rotation as a periodic housekeeping task instead of a response to exposure, ownership, and scope.
Practitioner guidance
- Remove secrets from environment files Move credentials out of .env files and into a controlled secrets manager, then block secrets from being committed to code, shared docs, chat systems, and CI/CD logs.
- Assign each secret a named owner and expiry path Record the business owner, technical owner, scope, and rotation requirement for every API key, SMTP credential, and service token so no secret can sit without accountability.
- Revoke exposed credentials before validating service continuity If a secret is found in a public or semi-public location, rotate or revoke it first, then test each dependent application, email flow, and API integration for breakage.
What's in the full article
Entro Security's full blog covers the operational detail this post intentionally leaves for the source:
- How the exposed .env file was discovered and what specific secrets were visible in the environment
- The vendor’s description of real-time discovery, anomaly detection, and context enrichment across secret stores and collaboration tools
- Operational examples of how the platform identifies excess privilege and misconfiguration across vaults, CI/CD, and third-party tools
- The vendor’s framing of how secrets, access control, and lifecycle management fit together in its product workflow
👉 Read Entro Security's analysis of the Neho secrets exposure incident →
Exposed secrets in cloud environments: what IAM teams missed?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
25/06/2026 5:39 pm
Secrets exposure is an identity governance failure, not a file hygiene issue. The Neho incident is best understood as non-human identity drift across a cloud environment, where credentials were left in a place that could be read, copied, and reused outside their intended lifecycle. OWASP-NHI and NIST-CSF both frame this as an access and asset governance problem, not just a data-leak event. The practitioner takeaway is that secrets must be governed as live identities, not static strings.
A few things that frame the scale:
- 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage, according to Ultimate Guide to NHIs.
- Another finding from the same research shows that 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
A question worth separating out:
Q: How can organisations reduce risk from third-party service credentials?
A: Inventory them as part of the same identity perimeter as internal secrets. Third-party email, messaging, and marketing credentials should have explicit owners, limited scope, and revocation procedures tied to offboarding and vendor change. Otherwise, the trust boundary extends far beyond the team that issued the key.
👉 Read our full editorial: Neho’s exposed secrets show how weak NHI governance fails
