On April 11, 2024, CISA took the unusual step of issuing a public advisory specifically about a breach at Sisense, a business intelligence and data analytics company. CISA urged all Sisense customers to immediately reset any credentials and secrets that had been shared with or accessible to Sisense. The advisory was notable both for its urgency and for the fact that CISA rarely issues advisories about breaches at individual companies.
The Sisense breach is a case study in third-party risk and the dangers of analytics platforms that, by design, require deep access to their customers' data.
What Happened
Details of the breach emerged gradually through a combination of CISA's advisory, independent reporting by journalist Brian Krebs, and limited communications from Sisense to their customers.
The attackers reportedly gained access to Sisense's GitLab code repository, which contained credentials and access tokens for Sisense's Amazon S3 buckets. These S3 buckets held terabytes of customer data, including the database connection strings, API keys, and access tokens that Sisense used to connect to customers' data sources.
The breach was significant because of what Sisense does. As a business intelligence platform, Sisense connects directly to customers' databases, data warehouses, and cloud services to generate dashboards and reports. To do this, customers provide Sisense with credentials to access their data sources, including databases containing financial records, customer information, operational data, and other sensitive assets.
When those stored credentials were compromised, the attackers potentially gained access not just to Sisense's own systems, but to the underlying data sources of every Sisense customer. The blast radius extended far beyond a single company.
CISA's Response
CISA's advisory recommended that all Sisense customers take the following steps:
- Reset credentials and secrets for all services accessed through the Sisense platform
- Investigate any unusual activity in systems that Sisense was configured to access
- Report any suspicious findings to CISA
The fact that CISA issued this advisory is itself significant. CISA typically publishes advisories about vulnerabilities, not individual company breaches. The decision to issue a public advisory suggests that CISA assessed the potential impact as widespread enough to warrant a national-level response.
CISA also stated they were "collaborating with private industry partners to respond to this incident" and were "taking an active role in working with the private sector to mitigate the impact." This language suggested that the scope of the compromise was substantial and that CISA had concerns about the potential for downstream exploitation.
The Third-Party Analytics Problem
The Sisense breach highlights a structural risk that many organizations accept without fully understanding. Business intelligence and analytics platforms, by their nature, require broad access to an organization's data. To generate dashboards and reports, they need to connect to databases, APIs, cloud storage, and other data sources.
This means that a BI platform typically holds:
- Database connection strings with read access (and sometimes write access) to production databases
- API keys for cloud services and SaaS platforms
- OAuth tokens with access to customer data
- Credentials for data warehouses containing historical business data
If the BI platform is compromised, all of those credentials are compromised. The attacker does not need to breach each customer individually. They breach the analytics platform once and gain access to the data sources of every customer.
This is not unique to Sisense. Any analytics, monitoring, or integration platform that connects to customer data sources carries this risk. The Sisense breach simply made the risk visceral and immediate.
Credential Storage and Supply Chain Trust
The root cause, credentials stored in a GitLab repository that also contained code with access to S3 storage, points to a common but dangerous practice: storing secrets in code repositories. Even in private repositories, this creates risk because:
- Repository access controls may be broader than credential access controls should be
- Repository clones exist on developer machines, CI/CD systems, and backup infrastructure
- A single compromise of the repository grants access to all stored credentials
The industry has spent years trying to move credentials out of code repositories and into dedicated secret management systems (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault). The Sisense breach demonstrates that this migration is still incomplete, even at companies whose entire business depends on securely handling customer credentials.
Lessons for Organizations Using Third-Party Platforms
The Sisense breach offers several practical lessons:
Audit what credentials you give to third-party platforms. Many organizations grant analytics tools database credentials with broad access because it is easier than configuring least-privilege access. Take the time to create dedicated service accounts with read-only access to only the specific tables and schemas the platform needs.
Use short-lived credentials where possible. Instead of static database passwords, use IAM-based authentication, temporary tokens, or credential rotation mechanisms that limit the window of exposure if credentials are stolen.
Monitor for anomalous access to your data sources. If your Sisense instance (or any analytics platform) starts querying data it does not normally access, or accessing data at unusual times, that should trigger an alert.
Include third-party platform compromises in your incident response planning. If your BI provider is breached tomorrow, do you know which credentials to rotate? Which data sources were accessible? How quickly can you revoke access?
Diversify your analytics architecture. If a single platform breach would expose all of your sensitive data sources, consider whether that concentration of risk is acceptable.
How Safeguard.sh Helps
Safeguard.sh provides the supply chain visibility that organizations need to manage third-party risk. Our platform tracks your software dependencies and integrations, helping you understand which components have access to sensitive data and credentials. When a vendor like Sisense discloses a breach, Safeguard.sh helps you quickly identify your exposure and prioritize the credential rotation and investigation steps needed to contain the blast radius. Our continuous monitoring approach ensures that third-party risk is assessed on an ongoing basis, not just at the point of vendor selection.