Sisense breach shows hardcoded tokens still drive cloud data theft

At a glance

What this is: This is an analysis of the Sisense breach and how exposed repository credentials enabled AWS access and data theft.

Why it matters: It matters because hardcoded secrets, repository sprawl, and over-privileged cloud access remain common failure points across NHI, autonomous, and human identity programmes.

👉 Read Unosecur's analysis of the Sisense breach and hardcoded token exposure

Context

Hardcoded credentials in source control create an identity problem as much as a code problem. Once a token or key is stored where attackers can reach it, the question shifts from application security to who can authenticate, what they can reach, and how quickly that access can be abused in cloud services.

The Sisense case sits squarely in NHI governance because the compromised token acted as a non-human identity with standing access into AWS and S3. That makes repository security, secret handling, and cloud entitlement scope part of the same control plane, not separate disciplines.

The breach is also a reminder that self-managed developer infrastructure increases the burden on configuration, review, and lifecycle discipline. The issue is not GitLab alone. It is the combination of exposed secrets, persistent access, and incomplete governance around machine credentials.

Key questions

Q: What breaks when a hardcoded secret is left in a repository?

A: A hardcoded secret turns source control into an authentication source. If an attacker finds it, they can often reuse it exactly as a workload would, bypassing normal user controls and expanding straight into cloud services or internal APIs. The fix is to remove the secret, revoke the token, and assume any repository copy is already compromised.

Q: Why do service account tokens create such large breach blast radii?

A: Service account tokens often carry broad, persistent access because they are built for machine-to-machine operation. When one is exposed, the attacker inherits whatever it can do, which may include listing storage, reading objects, or calling downstream services. Narrow scopes, short lifetimes, and fast revocation reduce that blast radius.

Q: How should security teams handle exposed AWS credentials in code repositories?

A: Treat exposed AWS credentials as an active incident, not a hygiene issue. Revoke the key pair, rotate dependent secrets, review CloudTrail for abnormal enumeration or download activity, and check whether the credential had write or export permissions. Repository cleanup matters, but cloud-side containment decides how far the breach goes.

Q: What should teams do when a self-managed GitLab instance stores secrets?

A: They should move secret detection into the development workflow, enforce least-privilege access to the repository, and review whether the platform itself is part of the identity boundary. Self-managed systems demand the same lifecycle discipline as any other credential-bearing service, including patching, logging, and entitlement review.

Technical breakdown

How hardcoded tokens in repositories become valid cloud identities

A hardcoded token is not just leaked text. In practice, it is a credential that can authenticate to cloud APIs, storage services, or internal platforms without further challenge. When developers embed secrets in a self-managed repository, the repository becomes both a code store and an identity store. If those secrets are not detected, rotated, and revoked, an attacker who reaches the repository can reuse the token exactly as a legitimate workload would. The cloud provider cannot distinguish whether the call came from a trusted application or a copied credential unless additional context and policy exist.

Practical implication: treat source control as a secret-bearing system and remove credentials before they ever reach the repository.

Why AWS and S3 access becomes a high-value exfiltration path

Once an attacker holds a valid AWS token, the next step is usually discovery. Storage APIs expose bucket listings, object metadata, and direct download paths that can reveal the layout of the environment before bulk exfiltration begins. Amazon S3 is especially attractive because it often contains backups, logs, certificates, tokens, and customer data in one place. The identity issue is not just that access exists. It is that the same credential can often enumerate, read, and export large volumes of data with little friction if policy boundaries are too broad.

Practical implication: constrain storage permissions so a single token cannot enumerate and extract whole data sets.

Why DevSecOps controls must cover secret lifecycle, not only code review

DevSecOps often focuses on pipeline security, but the Sisense pattern shows that secret lifecycle is the stronger control point. Scanning for tokens, rejecting commits that contain credentials, and continuously rotating exposed keys matter because the breach path begins before runtime monitoring can help. Once a token is reused, the attack is already inside the trust boundary. This is why repository security, secret detection, and access review have to operate as linked controls across development and cloud operations, not as isolated checks.

Practical implication: build secret detection and rotation into developer workflows, then back it with cloud-side access revocation.

Threat narrative

Attacker objective: The attacker objective was to use a leaked non-human credential to reach cloud storage and extract sensitive customer data at scale.

1. Entry occurred through a self-managed GitLab repository that exposed a hardcoded token tied to cloud access.
2. Credential abuse followed when the token was reused to authenticate to AWS and reach Amazon S3 resources.
3. Impact came from bulk access to stored data, including sensitive client information and other exposed secrets.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• IOS app secrets leakage report — iOS apps leaking hardcoded secrets and credentials endangering user privacy.

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 credentials are an identity governance failure, not just a secure coding defect. The Sisense pattern shows that a token stored in a repository can behave like an unmanaged service identity with standing cloud access. That turns source control into an identity attack surface and makes secret detection, revocation, and entitlement scope inseparable. The implication is that governance must cover where machine credentials live, how long they persist, and who can reuse them.

Standing cloud access is the failure mode this breach illustrates. The token appears to have granted enough privilege to reach AWS and Amazon S3 without a separate approval step or contextual check. That is a classic NHI control gap because a single credential inherited broad runtime reach once it was exposed. Practitioners should read this as a reminder that entitlement breadth, not just secret strength, determines breach impact.

Repository security and cloud security are one control domain when secrets are embedded in code. A self-managed GitLab environment adds operational responsibility for patching, configuration, access review, and secret hygiene. If those controls do not work together, an exposed token can survive long enough to be discovered, copied, and reused. The practical conclusion is that development systems must be governed as part of the identity perimeter, not treated as separate tooling.

Identity blast radius is the right named concept for this kind of breach. Once a hardcoded token was found, the attacker did not need a new foothold for every action. The same credential likely opened discovery, retrieval, and exfiltration paths inside AWS. That means the real question for practitioners is how much damage one leaked machine identity can do before it is invalidated.

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 credential problem can turn into repeated exposure.
• For a broader view of how leaked machine credentials create systemic exposure, see the 52 NHI breaches Report and compare the recurring control failures.

What this signals

Identity blast radius is now the practical measure that matters. In environments where a single secret can unlock storage, APIs, and downstream services, the governance question is no longer whether credentials exist, but how much they can reach before revocation. Teams that still treat repository secrets as a developer issue will keep missing the real containment boundary.

The control gap here is not subtle. When a token can be copied from code and used outside the intended workflow, existing approval and review cycles are already too late. That is why repository scanning, cloud telemetry, and revocation speed need to be managed as one programme rather than separate tools.

Programmes that map their machine identities to lifecycle ownership will respond faster because they know who can invalidate a token, who owns the cloud permission set, and which logs prove abuse. The operational question is whether your current IAM model can describe a secret's entire lifecycle before the next leak occurs.

For practitioners

• Block credentials from entering source control Enforce pre-commit and server-side scanning for API keys, tokens, certificates, and cloud secrets so repositories cannot become long-lived credential stores.
• Shorten the lifetime of every exposed machine credential Create a revocation workflow that invalidates leaked tokens immediately, then rotate dependent keys and certificates before normal incident handling completes.
• Reduce cloud storage blast radius Split S3 permissions so enumeration, read, and export rights are not bundled into one identity, and review any token that can list buckets and download objects.
• Govern self-managed developer platforms like identity infrastructure Treat GitLab configuration, access review, and secret handling as part of IAM operations, with ownership, logging, and periodic entitlement review.

Key takeaways

• The breach shows how a hardcoded token can function as a full cloud identity when repository hygiene fails.
• The impact was amplified by standing AWS and S3 access, which allowed a single exposed credential to drive broad data exfiltration.
• The limiting control is fast secret revocation combined with narrower cloud permissions and stronger repository scanning.

Key terms

• Hardcoded Secret: A hardcoded secret is a credential embedded directly in code, configuration, or a repository instead of being stored in a managed secrets system. It becomes especially dangerous because anyone who can read the file may be able to authenticate as the intended service or application.
• Standing Privilege: Standing privilege is access that remains valid all the time rather than being issued only when needed. For machine identities, it increases breach impact because a leaked token may already have the permissions required to enumerate, read, or export sensitive resources.
• Identity Blast Radius: Identity blast radius is the amount of damage an exposed identity can cause before it is revoked. It depends on scope, duration, and downstream dependencies, and it is a better operational measure than simply counting how many secrets exist.

What's in the full article

Unosecur's full blog covers the operational detail this post intentionally leaves for the source:

• Step-by-step walkthrough of how the exposed GitLab token was used to reach AWS services
• The specific CloudTrail and storage activity patterns Unosecur uses to detect exfiltration behaviour
• Practical examples of suspicious S3 actions such as bucket listing and repeated object downloads
• The remediation actions Unosecur recommends for repository cleanup, secret rotation, and incident response

👉 Unosecur's full post covers the GitLab root cause, AWS access path, and exfiltration indicators.

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 building or maturing an IAM programme, it is worth exploring.