Sisense breach shows why exposed secrets still drive NHI risk

At a glance

What this is: This is an analysis of the Sisense breach, which shows how exposed non-human identity secrets in source control can cascade into broader data exposure.

Why it matters: It matters because IAM, PAM, and NHI teams must treat secrets in code repos and storage accounts as lifecycle-controlled identities, not incidental implementation details.

Context

A leaked secret is not just a credential problem. In this breach, the security gap started in source control and expanded into storage access, where hardcoded credentials could reach customer data and downstream integrations.

For identity programmes, the issue is that non-human identities often span repositories, cloud storage, and SaaS integrations at the same time. When those credentials are exposed, the blast radius is defined by connected systems, not by the original repository alone.

Sisense's self-hosted GitLab choice also matters because it shifts responsibility for repository security, secret scanning, and credential governance back onto the organisation running it. That is a familiar failure pattern in NHI incidents.

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. Once a secret is exposed in source control, attackers often bypass the application entirely and use the identity the secret represents. That is why repository leakage is an identity governance issue, not just a coding mistake.

Q: Why do exposed NHI secrets create such a large blast radius in cloud environments?

A: Because one credential often unlocks many systems. Cloud keys, SSH credentials, CI/CD tokens, and Kubernetes secrets are reusable identity material, so theft from a single host can become access to multiple services, clusters, and accounts. Strong rotation helps, but only if the underlying secret sprawl is reduced.

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. Another signal is alert fatigue from scanners that cannot confirm whether a secret is still active or exploitable. If teams cannot map where secrets live or revoke them quickly, exposure is already operationally significant.

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.

Technical breakdown

How repository secrets become identity compromise

A hardcoded secret in source control is more than a coding mistake. It becomes a reusable authentication artefact that can be replayed against cloud services, APIs, and storage accounts. In NHI terms, the repository is the disclosure point, but the real risk is that the credential can be used outside its original intent and outside the developer workflow that created it. Once a secret is valid, the attacker does not need to exploit the application layer first. They simply authenticate as the workload or service account that the secret represents.

Practical implication: scan every commit and pull request for exposed secrets before code reaches shared repositories.

Why S3 exposure expands the blast radius

Cloud storage rarely contains only files. It often becomes a holding area for credentials, exports, logs, certificates, and tokens that other systems trust. In this case, the exposed S3 buckets reportedly contained customer data and additional NHI material, which means one credential compromise could uncover more credentials and more integration paths. That creates a compounding trust problem: access to one storage layer can lead to access to multiple connected services if those assets are not isolated and encrypted. The architecture issue is not just storage exposure, but identity reuse across systems.

Practical implication: treat storage buckets as identity-bearing assets and restrict what secrets can be stored there.

Why self-hosted repositories need stronger secret governance

Self-hosted source control does not remove vendor risk, but it does move repository security, logging, access control, and detection into the organisation's own operating model. That matters because NHI risk often grows where teams assume a self-managed system gives them more control by default. In reality, the control only exists if secret scanning, access reviews, and repository hardening are continuously maintained. Without those controls, the repository becomes a long-lived trust store for credentials that should have been transient or tightly segmented.

Practical implication: apply the same governance discipline to self-hosted code repositories that you would to production identity systems.

Threat narrative

Attacker objective: The attacker sought to turn one exposed repository secret into broader access across storage and connected customer-facing systems.

1. Entry occurred when attackers obtained access to Sisense's GitLab repository, which exposed hardcoded secrets tied to cloud resources.
2. Credential access followed when those secrets revealed access to AWS S3 buckets and related non-human identity material such as tokens and keys.
3. Escalation happened as access to one system opened paths to customer data and connected SaaS services that relied on the same credentials.
4. Impact was broad data exposure, with the breach affecting customer information and requiring credential changes across related environments.

Breaches seen in the wild

• Sisense breach 2024: A credential in Sisense's GitLab reportedly opened S3 buckets of customer tokens, passwords and certificates; CISA urged a full reset.

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

NHI Mgmt Group analysis

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.

Identity blast radius is now measured by connected trust, not by the first compromised system: Sisense's reported S3 exposure illustrates how one credential can surface multiple downstream assets, including customer data and additional access material. That means the security boundary is no longer the repository or the bucket in isolation. Practitioners need to think in terms of chained identity trust across source control, storage, and SaaS integrations.

Standing secret exposure window was the real failure mode here: The article shows a credential sitting in GitLab long enough to be found and used against cloud storage. That is a long-lived-secret problem, but more specifically it is a trust window that remained open across development and operations boundaries. The implication is that secret governance has to be treated as a runtime control, not a periodic audit activity.

Self-hosted platforms do not simplify non-human identity governance: When the organisation owns the repository stack, it also owns the detection, rotation, and access discipline needed to keep secrets from becoming persistence mechanisms. The security burden shifts, but the NHI risk does not. That makes repository governance part of the identity programme, not a separate developer tooling concern.

Non-human identity oversight must cover issuance, storage, and revocation as one lifecycle: The breach links code repositories, cloud storage, and third-party SaaS access into a single failure chain. That is why fragmented ownership between IAM, cloud, and engineering teams leaves gaps attackers can exploit. The practical conclusion is that secret custody has to be governed end to end.

From our research library:

• NHIs outnumber human identities by 25x to 50x in modern enterprises, according to the Ultimate Guide to NHIs.
• Read next: Ultimate Guide to NHIs — Key Challenges and Risks

What this signals

The useful lesson here is that source control, storage, and SaaS access should be governed as a single identity surface. If a secret can move from a repository into a bucket and then into customer-facing systems, the programme already has a lifecycle problem rather than a tooling problem.

This also sharpens a practical concept: identity blast radius. The question is not whether one secret was exposed, but how far that secret could travel before governance or detection intervened.

For practitioners

• 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.
• Separate repository access from production trust Do not let source control permissions imply production-level trust for machine identities; segment repository credentials, storage access, and SaaS integrations so one leak cannot span the estate.

Key takeaways

• The breach shows how a single hardcoded secret can become a reusable non-human identity that reaches storage and downstream services.
• The reported impact extended beyond code exposure into customer data and credentials, which is why the incident is an identity governance problem.
• The control gap is lifecycle discipline for secrets in repositories, storage, and integrations, not simply better developer hygiene.

Key terms

• Secrets Leakage: Secrets leakage is the exposure of credentials such as API keys, tokens, or certificates in places where they can be discovered and reused. The risk is not just disclosure, but unauthorized authentication that turns a coding or pipeline mistake into active access.
• Long-Lived Secret: A long-lived secret is a credential, token, API key, or certificate that remains valid for an extended period without frequent renewal. In NHI environments, it creates durable exposure because one leaked secret can keep granting access long after the original use case has changed.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
• Repository Security Scanning: Repository security scanning is the process of examining code, configuration, and related artefacts for exposed secrets, unsafe defaults, and misconfigurations. In MCP programmes, it helps catch hard-coded credentials and other deployment weaknesses before they become live access risks. Effective scanning should be continuous and policy-driven.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.