Topic starter
24/06/2026 5:47 pm
TL;DR: Unosecur's analysis of Sisense's 2024 breach finds hardcoded tokens in a self-managed GitLab repository led to AWS access and theft from Amazon S3. Secrets control works only when repository scanning, revocation, and cloud-use monitoring operate as one workflow.
Editorial analysis by NHI Mgmt Group, based on content published by Unosecur: “Safeguarding Secrets: Addressing Security Issues in Sisense”.
Key questions
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.
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.
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.
Practitioner guidance
- 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.
- 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.
Bottom line: The breach illustrates how a single hardcoded token can bridge development tooling and production cloud access.
Glossary terms: Hardcoded Token, Secrets Leakage, Secret Persistence Debt, Repository Credential
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.
👉 Read Unosecur's analysis of the Sisense hardcoded-token breach →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 6 days ago by NHI Mgmt Group
25/06/2026 3:43 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Sisense breach shows hardcoded tokens still drive cloud data theft