Sisense: a hardcoded token in the code repo unlocked terabytes of customer data

What happened

In April 2024, analytics vendor Sisense suffered a breach that led the U.S. Cybersecurity and Infrastructure Security Agency (CISA) to publicly warn customers on April 11 to reset any credentials and secrets they had shared with the company. According to sources cited by Krebs on Security, attackers gained access to Sisense's self-managed GitLab code repository, where they found a token or credential that gave them access to Sisense's Amazon S3 buckets. From there they copied several terabytes of customer data, reportedly including millions of access tokens, email-account passwords, and even SSL certificates.

Root cause

A long-lived secret that unlocked production cloud storage was stored in source control (CWE-798, hardcoded credentials). Once an attacker reached the repo, the crown-jewels credential was sitting in plaintext — no additional barrier stood between code access and terabytes of customer data. Access tokens made the blast radius worse: they let an attacker stay authenticated for long or indefinite periods without ever needing the original password. "The code builds and runs" was satisfied; "a repo compromise does not become a cloud-storage compromise" was never enforced.

How it would have been caught

A secret-scanning pass over the repository and its full git history — failing the build on any AWS key, token, or password — flags the credential before an attacker finds it. A blast-radius review would show that one repo secret grants direct S3 read: a finding that should force the secret out of code and into a short-lived, scoped credential. The reproduction is a grep of history that returns a live cloud credential.

How to prevent it

• Never store secrets in source. Use a secrets manager and short-lived, narrowly-scoped credentials; rotate on any suspicion.
• Run secret scanning on every push and over history; gate merges on a clean result.
• Segment blast radius: a repo credential should never grant broad production data access. Prefer per-service roles with least privilege.

The Breachwire test (red → green)

Run a secret scanner across the repository and its history and confirm it surfaces a working credential that authenticates to production storage — the RED proof that repo access equals data access. Remove the secret, rotate it, replace it with a short-lived scoped role, and confirm the scanner returns no live secrets and that the old credential no longer authenticates.