Topic starter
24/06/2026 5:47 pm
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.
Editorial analysis by NHI Mgmt Group, based on content published by Unosecur: “Safeguarding Secrets: Addressing Security Issues in Sisense”.
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.
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.
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.
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 →
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