Notifications
Clear all
Topic starter
25/06/2026 5:04 pm
TL;DR: Sisense’s April 2024 breach exposed hardcoded credentials in a GitLab repository and led to customer data exfiltration, with CISA urging password and token changes across affected environments. The incident shows that secrets exposure, unencrypted storage, and weak NHI oversight can cascade across connected systems faster than traditional review cycles can catch up.
NHIMG editorial — based on content published by Entro Security covering the Sisense breach: The Sisense breach: Our key takeaways & offer to help any affected organization
Questions worth separating out
Q: What breaks when a hardcoded secret is exposed in source control?
A: A hardcoded secret turns source control into an authentication surface.
Q: Why do service account and API key exposures create outsized cloud risk?
A: Service accounts and API keys are often bearer credentials with broad, persistent reach.
Q: How do security teams know whether secret rotation is actually reducing risk?
A: Rotation is working only if it shortens the time a leaked credential remains usable and removes old values from every dependent system.
Practitioner guidance
- Scan source control for secrets continuously Run secret-detection on every commit, branch, and pull request, and block merges when credentials, tokens, or certificates appear in code or config files.
- Map where integration secrets actually live Build an inventory of repositories, buckets, vaults, and CI pipelines that store reusable credentials so you can remove secrets from any place that also stores sensitive data.
- Rotate exposed credentials in dependency order Start with the secrets that unlock the most sensitive buckets and services, then work outward through linked SaaS and cloud accounts until the full trust chain is reset.
What's in the full article
Entro Security's full blog post covers the operational detail this post intentionally leaves for the source:
- The incident timeline and the specific customer notifications that followed the breach
- Entro Security's remediation offer, including its 90-day retrospective scan for impacted organisations
- The vendor's step-by-step advice on rotating secrets, tokens, keys, and SaaS credentials
- Operational details on how its platform claims to surface anomalous NHI usage across cloud and on-prem systems
👉 Read Entro Security's analysis of the Sisense breach and exposed secrets →
Sisense breach and exposed secrets: what IAM teams should note?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
25/06/2026 5:32 pm
Hardcoded secrets are not isolated mistakes, they are reusable identity failures. The Sisense breach shows that a single committed credential can become a durable authentication path into storage, cloud services, and downstream integrations. That is an NHI governance problem, not just a secure-coding problem. The practical conclusion is that source control must be treated as an identity boundary.
A few things that frame the scale:
- 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, according to The 2024 ESG Report: Managing Non-Human Identities.
- Enterprises that have experienced a compromised NHI averaged 2.7 separate incidents in the past 12 months, which shows how quickly one identity failure can repeat.
A question worth separating out:
Q: Who is accountable when a repository secret exposes customer data?
A: Accountability usually spans application teams, platform teams, and identity owners because the failure crosses code, storage, and access governance. Frameworks such as NIST CSF and OWASP NHI both push organisations to assign clear ownership for credential lifecycle, exposure detection, and downstream revocation.
👉 Read our full editorial: Sisense breach shows why exposed secrets still drive NHI risk
