Over the past few weeks, our CEO, Jason Smith, shared two public updates about the security incident that occurred in June: an initial account of what happened and a summary of CrowdStrike’s investigation and the improvements we made.
As Klue’s CTO and co-founder, I want to share what the incident and our response brought into sharper focus, the changes we have made and the lessons that may be useful to other CTOs and security professionals.
One point is important at the outset: this was a deliberate intrusion, not an outage or a software bug.
What Happened
The incident originated with a GitHub Personal Access Token with access to Klue’s GitHub environment.
It unfolded in two distinct phases. During the first phase, the attacker used that access to download source code, obtain an additional GitHub Personal Access Token, identify additional credentials and test whether any of those identified remained active, all while moving quietly and remaining undetected. Once ready to act, the activity accelerated rapidly into the second phase. The attacker introduced unauthorized code through a build and deployment path, resulting in a tampered workload being deployed to production. Within minutes, the malicious code transmitted integration credentials and enabled unauthorized access to stored OAuth tokens associated with certain customer integrations.
When the activity was identified, we disabled the affected workloads, revoked the compromised GitHub tokens, rotated credentials under our control and took the integration service offline. Containment was completed on June 12. CrowdStrike subsequently conducted an independent forensic investigation and found no evidence of attacker activity in Klue’s environment after those containment actions on June 12, 2026.
Klue nor CrowdStrike was able to determine how the first GitHub Personal Access Token was initially exposed.
Existing Controls and Their Role
Klue had an established security program before the incident, including SOC 2 Type II compliance, independent annual penetration testing, periodic access reviews, dependency scanning, mandatory code review, branch protection and extensive logging.
Several existing controls were relevant to how the incident unfolded:
- Main branch protections rejected the attempt to push the malicious change directly.
- In one connected platform, the read-only scope of a credential limited the attacker’s ability to take further action.
- Extensive logging helped us reconstruct the attack, understand the behaviour of the malicious code and assess the amount of information moved from Klue.
These controls played different roles across prevention, impact reduction and investigation. The incident reinforced the importance of defence in depth, with multiple independent controls working together across the environment.
The incident also required us to examine the conditions that made the intrusion possible and make meaningful enhancements to how we protect the platform.
How We Strengthened Klue
We focused our response on closing the access path used in the incident, improving detection and containment, and reducing systemic credential risk.
1. GitHub and CI/CD
We blocked GitHub personal access tokens across the organization and migrated affected workflows to GitHub Apps, short-lived credentials and Workload Identity Federation.
We also strengthened source verification, secret scanning, deployment protections, runner restrictions and default-deny network controls.
2. Detection and containment
We expanded and centralized monitoring across GitHub, our cloud environments, CI/CD workflows and developer endpoints, with additional alerting for suspicious activity and stronger automated containment.
3. Credential and integration security
We are reducing the number of long-lived credentials that Klue stores. Where stored credentials remain necessary, and where vendor support exists, we are making them shorter-lived, more narrowly scoped and restricted to the relevant workload, identity and network context.
For OAuth integrations, we are adopting stronger controls where supported, including PKCE, refresh-token rotation, idle refresh-token expiration, IP-range allow-listing and shorter session lifetimes.
Where possible, we are also moving toward models in which customers or platform providers send Klue only the approved data needed for an integration.
4. Broader security baseline
We have also strengthened authentication, privileged access, threat modelling and oversight of sensitive integrations.
Some of these measures have been completed, and validated by CrowdStrike. Others remain part of our longer-term security roadmap.
What This Incident Reinforced
The investigation and response brought four important security principles into sharper focus for me, reflecting issues that have received growing attention across the SaaS industry and that warrant continued discussion.
1. Persistent credentials create persistent risk
In this case, a GitHub Personal Access Token created in 2022 for a third-party vendor pilot-project remained capable of accessing Klue’s GitHub environment, even though the related build artifacts were never deployed to production.
The clearest architectural shift is not simply to protect long-lived credentials more carefully, but to reduce the need for them wherever possible. Put differently, I would rather remove a target than win the race to protect it.
Long-lived credentials remain common across SaaS integrations for practical reasons. Frequent expiration can interrupt automated workflows, break integrations and create operational friction. But the security model has to move beyond simply keeping credentials safe. It also has to limit the impact if they are exposed.
Where credentials remain necessary, our approach is to keep them short-lived, narrowly scoped, bound to a specific workload or identity, restricted in where they can be used and limited to the permissions required for the task.
2. CI/CD is part of the production security boundary
The deployment path used in the incident reinforced why CI/CD must be treated as part of the production security boundary.
The attacker did not need to merge code into the protected main branch to affect a production workload. Another route through the build and deployment process was used.
Branch protection and code review still matter, but they are only part of the system. Build infrastructure, deployment workflows, runners, accepted source history and network egress all require the same level of scrutiny as the applications they deliver.
The broader system needs to verify what is being built, where it came from and whether it is authorized to run.
The investigation also showed how OAuth risk can span the SaaS provider, the platform holding the data and the customer account used to authorize access.
OAuth supports much of the SaaS integration model, but the practical reach of a token often depends on both the permissions requested by an application and the privileges held by the account used to authorize it.
An application may request a defined set of permissions, while the resulting token may still reflect broader privileges held by the authorizing account. Depending on how that account is configured, the token may be able to reach more than the integration requires.
Least privilege therefore has to be a shared priority. Platform providers can make narrower authorization options available. SaaS providers need to request only the scoped access they require and apply stronger token-lifecycle controls. Customers can use dedicated, low-privilege integration accounts where those options are supported.
Scopes, account privileges and token behaviour need to be reviewed together.
4. Incident evidence may be distributed across several parties
Our response reinforced another practical challenge: no single organization necessarily holds the complete record of an incident involving connected platforms.
Klue investigated what happened inside our environment. Understanding activity within customer or platform environments required logs held by those organizations.
That is not unusual in a connected SaaS ecosystem, but it matters for the speed of incident response.
Effective response across the ecosystem also has to be collaborative. I met with many customer CISOs and security teams to provide timely and accurate information they could use to build the most complete picture of their environments. Successful incident-response requires all involved vendors to act with urgency to share essential information with customers.
Where We Go From Here
Containment was only the first step. The work that followed required a thorough investigation, significant improvements to the platform and a clear view of where we needed to go further.
The credential and CI/CD paths used in the incident have been addressed, and Klue is stronger today because of the changes we have made. We are also continuing to reduce our reliance on long-lived credentials and strengthen how integrations are authenticated, monitored and protected.
On a more personal note, I have spent much of my career in cybersecurity studying incidents from the outside. Experiencing one first-hand confirmed something simple: security incidents are about trust.
They begin when trust is abused, whether in a credential, a system or an integration. They are contained and investigated through cooperation between customers, vendors, partners and responders working under pressure with incomplete information. They are remediated by narrowing trust, verifying it more often and limiting what any one credential or system can do.
Ultimately, trust is reinforced through actions, not assurances.
That is the work we are committed to. We will continue to protect our customers, act with accountability and invest in making our architecture more secure and resilient.
To our customers: thank you for your patience, scrutiny and partnership throughout this process.
Sarathy Naicker
CTO and Co-founder, Klue
SHARE THIS POST