Topic starter
25/06/2026 5:04 pm
TL;DR: The Sisense breach began with hardcoded secrets in a GitLab repository, then exposed AWS S3 buckets holding customer data and credentials, showing how one leaked secret can cascade across connected systems faster than review cycles can react, according to Entro Security. Secret exposure is still an identity governance problem, not just a code hygiene issue.
Editorial analysis by NHI Mgmt Group, based on content published by Entro Security: “The Sisense breach: Our key takeaways & offer to help any affected organization”.
Key questions
Q: What breaks when secrets are committed to source control?
A: The main failure is that a credential becomes reusable outside the developer workflow and can authenticate directly to cloud storage, APIs, or SaaS integrations.
Q: Why do exposed NHI secrets create such a large blast radius in cloud environments?
A: Because one credential often unlocks many systems.
Q: What are the signs that exposed repository secrets are becoming an active security problem?
A: Warning signs include secrets appearing in commit history, config files, or abandoned repositories, especially when multiple environments and developer machines are involved.
Practitioner guidance
- Implement commit-level secret scanning Scan every repository commit and pull request for hardcoded secrets, then block merges when tokens, keys, certificates, or passwords appear in code or config files.
- Inventory cloud storage for embedded credentials Search S3 buckets, export locations, and shared file stores for tokens, SSH keys, API keys, and certificates that may have been stored outside approved secret vaults.
- Rotate exposed NHI secrets in sequence Prioritise the oldest and most privileged secrets first, then rotate downstream credentials used by connected SaaS accounts, storage services, and integration pipelines.
Bottom line: The breach shows how a single hardcoded secret can become a reusable non-human identity that reaches storage and downstream services.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 5 days ago by NHI Mgmt Group
25/06/2026 5:32 pm
Secret leakage is still an identity control failure, not a code review miss: This breach shows that exposed credentials become living non-human identities the moment they are committed to shared systems. The failure is not only that a secret existed, but that its lifecycle was not contained once it left the developer workstation. For identity teams, the issue is governance over where a credential can exist at all.
A few things that frame the scale:
- NHIs outnumber human identities by 25x to 50x in modern enterprises, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: How should teams respond when a self-hosted repository exposes secrets?
A: Treat the repository as only one part of the problem. Revoke and rotate the exposed secrets, review the downstream SaaS and storage accounts they can reach, and verify whether other credentials were stored in the same location. Self-hosted systems demand the same lifecycle discipline as any production identity platform.
👉 Read our full editorial: Sisense breach shows why exposed secrets still drive NHI risk
This post was modified 5 days ago by NHI Mgmt Group