TL;DR: Unosecur reports that Sisense's 2024 breach began in a self-managed GitLab repository where hardcoded tokens enabled AWS access and theft from Amazon S3, underscoring how exposed credentials can still turn source control into cloud compromise. Secrets governance fails when repository hygiene, token lifecycle, and cloud monitoring are treated as separate problems.
At a glance
What this is: Unosecur analyses the Sisense breach as a hardcoded-token incident that moved from GitLab exposure to AWS access and S3 data theft.
Why it matters: It matters because IAM, NHI, and DevSecOps teams have to govern repository-stored secrets as active credentials, not passive code artefacts.
👉 Read Unosecur's analysis of the Sisense hardcoded-token breach
Context
Hardcoded credentials become an identity problem the moment they are accepted by infrastructure, because they behave like standing access rather than temporary build artefacts. In this case, the governing failure was not just leaked code, but a secret lifecycle that allowed a repository token to remain valid long enough to reach AWS and Amazon S3.
Sisense's breach is a classic example of why secrets management, repository governance, and cloud access monitoring belong in the same control plane. When credentials live in source control, the attack surface shifts from application logic to non-human identity governance, where discovery, rotation, revocation, and auditability must be continuous.
The article's starting position is typical for modern cloud environments: one exposed token can bridge development systems and production data services if lifecycle controls are weak.
Key questions
Q: What breaks when Git tokens and hard-coded secrets are left in source control?
A: Source control becomes an access path instead of a safe delivery system. A single leaked token can unlock private repositories, reveal additional credentials in code, and give attackers a repeatable way into cloud and SaaS services. The failure is not just exposure. It is the absence of lifecycle control and detection around identity-bearing artefacts.
Q: Why do exposed secrets create such a large share of cloud infrastructure incidents?
A: Exposed secrets are dangerous because they turn leaked credentials into immediate access paths. API keys, tokens, and similar secrets often bypass normal user controls, so attackers can move directly into cloud services, data stores, or workloads. Once a secret is found, abuse can start quickly, and revocation delays usually widen the impact window.
Q: How do organisations know whether secret scanning is actually working?
A: Look for fewer valid secrets left in circulation after detection, not just higher detection counts. Working programmes can show fast owner assignment, reliable false-positive suppression, and automated invalidation before a secret can be reused. If alerts do not change credential status, the control is informational rather than protective.
Q: What should teams do when exposed credentials are found in a public repository?
A: Treat the repository as an entry point, not the whole incident. Revoke the exposed credential, trace every service and role it could access, and look for adjacent secrets stored in exports, configs, and workstation files. Containment has to follow the privilege graph, not just the leak location.
Technical breakdown
How hardcoded tokens become standing cloud access
A hardcoded token is a credential embedded in code, configuration, or a repository where it can be read and reused outside its intended workflow. Once a token authenticates successfully, the cloud provider treats it as a valid identity with whatever permissions were attached at issuance. That makes the real risk the mismatch between how casually the secret was stored and how much power the credential still carries. In a GitLab-hosted development workflow, repository compromise is only the entry point; the blast radius depends on what the token can do in AWS and how long it remains valid.
Practical implication: treat repository-stored secrets as live NHI credentials with explicit scope, expiry, and revocation paths.
Why self-managed GitLab increases secret governance burden
Self-managed GitLab shifts more security responsibility onto the organisation because configuration, access controls, and monitoring must all be maintained locally. That matters when repositories contain access tokens, API keys, or cloud credentials, because the platform cannot compensate for weak secret hygiene or poor visibility. The relevant failure mode is not GitLab itself, but the absence of enforced secret discovery and repository access governance around it. If a token can be committed, copied, and later used to reach cloud services, then the repository has become part of the credential estate.
Practical implication: align repository controls with NHI governance so source control is monitored like any other credential repository.
How AWS and S3 exposure follows credential compromise
When a valid cloud token is used after exposure, the attacker is no longer breaking authentication, but operating as an authorised principal. In this case, access to Amazon S3 created a direct path to object listing, bulk retrieval, and exfiltration of customer data and related secrets. That pattern is especially damaging because S3 often holds both the target data and the credentials that open other systems. Monitoring therefore has to focus on abnormal use of authenticated actions, not just login failures or malware indicators.
Practical implication: monitor cloud API behaviour for unusual object access, not only for failed authentication events.
Threat narrative
Attacker objective: The objective was to use an exposed repository token to reach cloud storage and steal sensitive client data and related secrets.
- Entry occurred through a hardcoded token discovered in Sisense's self-managed GitLab repository, giving attackers a valid credential path into the environment.
- Credential use then enabled access to Sisense's AWS account and Amazon S3 storage, turning source-code exposure into authorised cloud activity.
- The final impact was data exfiltration, including sensitive client data and other credentials reportedly held in the S3 bucket.
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.
- Internet Archive breach 2024: An exposed GitLab token opened Internet Archive code and 31 million user records; unrotated Zendesk tokens let the attacker back in weeks later.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Hardcoded tokens are not code hygiene issues, they are live identity assets. The Sisense incident shows that once a credential is committed to a repository, it behaves like standing privilege until it is discovered and revoked. That collapses the usual boundary between development artefact and production access. For identity teams, the governance unit is the secret itself, not the file that contains it.
Secret sprawl in source control creates an identity blast radius that DevSecOps alone cannot contain. When tokens, passwords, and certificates are scattered across repositories, the control problem becomes inventory, ownership, and revocation at scale. This is why secrets management has to sit alongside IAM and NHI governance rather than beneath them as an engineering task. The practitioner conclusion is simple: if a repo can mint cloud access, it is part of the access estate.
Repository compromise becomes cloud compromise because many organisations still trust static credentials inside dynamic environments. That trust assumption was already fragile before cloud adoption, and it fails harder when a single token can open object storage, connected applications, or vendor integrations. The named concept here is credential persistence debt: the longer a secret remains valid after exposure, the more it compounds into downstream loss. Teams should measure and reduce that debt, not just scan for leaks.
Cloud data theft from exposed credentials is now a lifecycle failure, not a perimeter failure. The breach illustrates why OWASP-NHI controls on secret leakage, long-lived secrets, and improper offboarding map directly to modern cloud identity risk. Once a repository secret can be reused elsewhere, the question is no longer whether the environment is protected at the edge, but whether every non-human credential has a revocation path that actually works. Practitioners should govern secret lifecycle as a first-class security process.
Detection has to move from compromise discovery to credential-use anomaly detection. The article's monitoring examples show the right direction: bucket listing, bulk object retrieval, and unusual access patterns are the signals that matter after a secret is abused. That means cloud telemetry, repository scanning, and secret rotation are complementary controls, not substitutes. The field implication is that identity security for machines must be measured by how quickly abuse is constrained after exposure.
From our research library:
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
- Read next: Guide to the Secret Sprawl Challenge
What this signals
Credential persistence debt: the longer a secret survives after exposure, the more likely it is to become a cloud access path rather than a harmless leak. Teams need to measure how quickly repository-stored secrets are found, revoked, and replaced, because dormant credentials expand the blast radius long after the commit is made.
Source control and secrets management cannot be separated in modern IAM programmes. A repository that can store reusable cloud tokens is already part of the non-human identity estate, which means secret scanning, ownership, and lifecycle control have to be enforced as governance, not optional tooling.
The developer behaviour gap matters because controls fail where users do not follow the workflow. If only 44% of developers are reported to follow security best practices for secrets management, organisations should assume that code review alone will miss a material share of exposed credentials.
For practitioners
- Audit repositories for embedded cloud credentials Scan source control, CI variables, and configuration files for access tokens, API keys, and certificates that can authenticate to production services. Prioritise repositories with broad contributor access and high-impact cloud integrations.
- Rotate exposed tokens and invalidate dependent sessions Revoke any credential found in code or logs, then check whether the same secret was copied into downstream systems, integrations, or backups that also need invalidation.
- Treat self-managed GitLab as part of the credential estate Review repository permissions, secret-detection coverage, and administrative ownership for self-managed GitLab instances so they are governed with the same discipline as secrets vaults.
- Monitor cloud storage for abnormal authenticated activity Alert on bucket enumeration, bulk object reads, repeated metadata checks, and unusual access sequences that indicate a valid token is being abused after compromise.
Key takeaways
- The breach illustrates how a single hardcoded token can bridge development tooling and production cloud access.
- The incident path moved from GitLab exposure to AWS access and S3 data theft, showing that secret lifecycle failure can quickly become data loss.
- The strongest control change is to govern repository secrets as live credentials, with scanning, revocation, and cloud-use monitoring as one workflow.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The breach began with a token left exposed in GitLab and reused against cloud resources. |
| NHI-07 — Long-Lived Secrets | The attack only worked because the compromised token remained valid long enough to be abused. | |
| NHI-05 — Overprivileged NHI | Any secret that can reach production storage creates excessive blast radius when exposed. | |
| Recommendation — Scan repositories for exposed secrets and revoke any credential discovered in code or logs. Replace persistent credentials with short-lived secrets and enforce expiry across cloud access paths. Limit NHI permissions to the minimum object and bucket scope needed for each integration. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The incident hinges on the lifecycle management of authenticators and their revocation. |
| Recommendation — Apply authenticator management controls to rotate, revoke, and reissue exposed machine credentials quickly. | ||
| MITRE ATT&CK | TA0006;TA0010 — Credential Access; Exfiltration | The attack chain moved from credential use to data theft through cloud storage. |
| Recommendation — Map exposed-token incidents to credential access and exfiltration behaviours in your detection pipeline. | ||
Key terms
- Hardcoded Token: A hardcoded token is a reusable credential embedded in code, configuration, or a repository instead of being issued and managed through a secrets workflow. In practice it behaves like a live non-human identity credential, which means exposure can create immediate access unless it is revoked and replaced.
- 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.
- Secret Persistence Debt: Secret persistence debt is the growing security liability created when exposed credentials remain valid for too long after they are discovered or copied. It is a lifecycle problem, not just a detection problem, because every extra hour of validity expands the window for cloud abuse and data exfiltration.
- Repository Credential: A repository credential is any secret that grants access to a source code management system, including passwords, tokens, SSH material, or SAML-linked access. These credentials are especially sensitive because they often unlock code, configuration, and additional secrets that can be reused against other internal systems.
What's in the full article
Unosecur's full blog covers the operational detail this post intentionally leaves for the source:
- The step-by-step root cause discussion for the Sisense breach, including the self-managed GitLab and AWS access path.
- The specific AWS CloudTrail-style behaviours Unosecur says can indicate S3 exfiltration after credential compromise.
- The article's incident-response guidance on secret rotation, certificate replacement, and account review after exposed tokens.
- The FAQ examples that map the breach into practical remediation questions for IAM and DevSecOps teams.
👉 Unosecur's full blog covers the GitLab exposure path, S3 theft, and response considerations.
Deepen your knowledge
NHI governance, secrets management, and machine identity security 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.
Published by the NHIMG editorial team on June 23, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org