Sisense breach shows why exposed secrets still drive NHI risk

At a glance

What this is: This is an analysis of the Sisense breach showing how exposed secrets in source control can cascade into broader non-human identity compromise and data exfiltration.

Why it matters: It matters because IAM, PAM, and NHI teams need to treat source control, token sprawl, and secret rotation as one governance problem rather than separate controls.

👉 Read Entro Security's analysis of the Sisense breach and exposed secrets

Context

Secrets exposure is not just a developer hygiene issue. In an NHI programme, a single credential in source control can become the entry point to buckets, APIs, and downstream SaaS integrations that were never meant to be exposed together.

Sisense is a useful case because it shows how hardcoded credentials, unencrypted data at rest, and broad integration surfaces combine into one governance failure. The question for IAM teams is not whether one secret was leaked, but why one leaked secret could touch so many identities and systems.

That starting position is typical of modern SaaS and platform environments, where machine access is distributed across code, storage, and federated services.

Key questions

Q: What breaks when a hardcoded secret is exposed in source control?

A: A hardcoded secret turns source control into an authentication surface. Once exposed, it can be reused to access storage, cloud services, and connected SaaS tools until it is revoked or rotated. The main failure is not the leak itself but the reuse path it creates across non-human identities and downstream integrations.

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. If they are stored in code, logs, or buckets, they can be replayed without human approval and used to move laterally across systems. That is why non-human identity governance has to focus on scope, lifespan, and storage location.

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. Teams should measure how quickly exposed secrets are found, revoked, and replaced, then verify that no backups, scripts, or integrations still reference the old credential.

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.

Technical breakdown

How a hardcoded secret becomes a platform breach

A hardcoded secret in a Git repository is not merely a leaked password. It is a reusable bearer credential that can authenticate a machine, script, or external service without a person in the loop. Once discovered, the credential can be replayed until it is rotated or revoked. In the Sisense case, the exposed repository appears to have provided access to AWS storage that held large volumes of customer data and additional credentials. That is the defining danger of NHI exposure: the first secret is often only the first door.

Practical implication: scan every commit and branch for secrets before code reaches production.

Why one bucket can unlock many downstream identities

Cloud storage often becomes a credential cache by accident. Teams store tokens, keys, certificates, and integration secrets alongside product data because those artefacts are easy to move and hard to govern. The problem is that each stored secret can extend access to other services such as Salesforce, Snowflake, or cloud control planes. That turns a single compromised object into a trust chain across multiple NHI domains. The architectural failure is not only exposure, but concentration of privilege in one place with too little lifecycle control.

Practical implication: inventory where secrets are stored and remove them from any system that also holds sensitive data.

Why encryption and rotation are different controls

Encryption at rest reduces exposure if an attacker only gets the raw storage file, but it does not solve credential compromise. Rotation changes the validity of a secret, while encryption protects the data payload. These are complementary controls, not substitutes. In NHI governance, organisations often overestimate storage protection and underestimate identity protection. The Sisense pattern shows why credential scope, rotation cadence, and data encryption must be reviewed together, especially where service accounts and API keys can reach multiple business-critical systems.

Practical implication: pair at-rest encryption with aggressive secret rotation and entitlement review.

Threat narrative

Attacker objective: The attacker’s objective was to pivot from a single exposed repository into broader access to customer data and connected service credentials.

1. Entry began when attackers reached a Sisense GitLab repository that contained hardcoded credentials tied to cloud storage access.
2. Escalation followed when those credentials were used to reach AWS S3 buckets that held additional secrets, tokens, keys, and certificates.
3. Impact came through exfiltration of customer data and the exposure of downstream machine identities that could unlock other integrated services.

Breaches seen in the wild

• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Secret concentration creates identity blast radius. When storage systems hold tokens, SSH keys, API keys, and certificates alongside customer data, the compromise of one control plane becomes the compromise of many identities. The article’s core lesson is that access topology matters as much as access volume. Practitioners should recognise that broad integration stacks amplify the effect of any one exposed credential.

Standing credential exposure window: this breach worked because a secret remained valid long enough to be found, reused, and chained into additional access. That assumption was designed for credentials managed on stable review cycles. It fails when a leaked credential can be replayed immediately across multiple systems. The implication is that lifecycle governance must account for runtime exposure, not just periodic review.

Encryption at rest does not compensate for identity failure. Protected data is still vulnerable when the authentication path into it has already been exposed. The article reinforces a discipline-wide point: the control that failed first was secret governance, and the downstream data controls only limited the damage. Practitioners should stop treating storage encryption as a substitute for NHI containment.

Cross-domain governance is now the baseline for SaaS platforms. Sisense connected cloud services, code repositories, and customer integrations in a way that made one exposed credential operationally meaningful across multiple environments. That is exactly where IAM, PAM, and NHI oversight need to converge. The practitioner takeaway is to govern the trust chain, not the individual system in isolation.

From our research:

• 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.
• Use 52 NHI Breaches Analysis to compare this pattern with other real-world secret exposure and credential cascades.

What this signals

Identity blast radius: teams should expect the next breach to move from repository compromise into storage, then into SaaS and cloud integrations if secrets are not isolated. The governance shift is from protecting individual systems to mapping where reusable credentials can traverse the environment, especially where source control and object storage intersect.

With 85% of organisations lacking full visibility into third-party vendors connected via OAuth apps, the same visibility problem that affects delegated access also affects secret-driven trust chains. That means IAM programmes need unified control over credential storage, third-party access, and revocation paths.

For practitioners, the next step is to align secret detection with lifecycle governance and incident response, then test whether old credentials still work in backups, scripts, and connected services. If they do, the trust chain is still live.

For practitioners

• 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.
• Review unencrypted storage for embedded identity material Check whether object stores, backups, or exports contain tokens, SSH keys, API keys, or certificates that expand the blast radius of a repository compromise.

Key takeaways

• The Sisense breach shows that one exposed secret can become a platform-wide identity problem when credentials are stored near customer data and reused across integrations.
• The evidence points to a familiar NHI pattern: source-control leakage, downstream storage access, and broad credential reach create a large blast radius from a single mistake.
• Practitioners should focus on continuous secret scanning, fast rotation, and trust-chain mapping so that a leaked credential cannot keep extending access.

Key terms

• Hardcoded Secret: A hardcoded secret is a credential placed directly into code, configuration, or repository content. It is dangerous because anyone who finds it can often reuse it without additional approval, which turns a development mistake into a live identity compromise across connected systems.
• Identity Blast Radius: Identity blast radius is the amount of access, systems, and data that can be reached once one credential or account is compromised. In NHI environments, it expands quickly when tokens, keys, and certificates are reused across storage, APIs, and SaaS integrations.
• Secret Rotation: Secret rotation is the controlled replacement of credentials, tokens, or keys so old values can no longer be used. It matters because a leaked credential remains a live threat until every system that trusts it has been updated and the old value is retired.

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

👉 The full Entro Security post covers the breach timeline, remediation guidance, and its offer to scan affected environments

Deepen your knowledge

NHI governance, machine identity security, and secrets management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or programme maturity, it is worth exploring.