On November 1, 2022, Dropbox published a blog post describing an incident in which a successful phishing campaign against Dropbox employees had resulted in an attacker gaining access to 130 of the company's GitHub repositories. The disclosure was prompt, detailed, and unusually explicit about the tradecraft involved. In the months since, the incident has become a reference case for how modern CI/CD dependencies reshape the attack surface of engineering organizations, and for how the boundary between "internal" and "supply chain" has collapsed.
What happened
The publicly documented narrative begins in early October 2022. Several Dropbox engineers received emails purporting to come from CircleCI, Dropbox's continuous integration vendor at the time. The emails used CircleCI's visual branding, referenced the need to update terms of service or authenticate a new feature, and directed recipients to a fake CircleCI login page. The login page harvested GitHub credentials and a time-based one-time password, because Dropbox engineers authenticated to CircleCI via GitHub SSO. At least one engineer entered credentials that were promptly used to authenticate as that engineer to GitHub.
Once authenticated to GitHub, the attacker accessed 130 repositories containing Dropbox's internal code, some third-party library copies, and a small number of credentials embedded in source. Dropbox stated that none of the repositories contained core Dropbox product code or user content, and that its production environment was segregated from the affected GitHub instance. The company rotated the exposed credentials, revoked the compromised session, and retained an external firm to conduct a forensic review. Regulatory disclosure followed in several jurisdictions.
The CircleCI angle
What made the Dropbox incident a supply chain story was not merely that the phishing pretext referenced CircleCI. CircleCI itself disclosed a separate, unrelated breach of its own systems in January 2023, unconnected to the Dropbox lure but thematically related: CI systems are high-value targets because they aggregate credentials for source repositories, container registries, cloud accounts, and package registries. A compromised CI account is, in practice, a compromised blast radius across those endpoints.
The phishing campaign against Dropbox exploited this aggregation. The attacker did not need to steal a GitHub personal access token directly; they used an email lure themed on CircleCI to coerce an engineer to authenticate via GitHub SSO on a phishing page, capturing the OAuth flow's outputs. The trust relationship between CircleCI and GitHub, routine, necessary, and nearly universal among modern engineering orgs, was the pivot.
This is the generalizable lesson. Every SaaS tool that federates authentication with a code host expands the phishing surface of that code host. Every CI vendor that stores long-lived secrets for deployment targets becomes a concentrated target. Every "Login with GitHub" or "Login with Google" button, once normalized across an organization, becomes a reusable attack primitive.
What the attacker obtained and did not obtain
Dropbox's disclosure emphasized that no production data, customer content, or core product code was exposed. The 130 compromised repositories contained internal libraries, copies of third-party code, and some operational credentials. The absence of customer impact is attributable to design choices that predate the incident: source repositories used for development were separated from repositories and systems that held production secrets, production deployment required independent credentials, and sensitive customer data lived in systems that were not reachable from the GitHub tenant.
This separation is worth calling out because it is neither universal nor free. Many engineering organizations maintain a single GitHub tenant with production deployment keys configured as repository secrets. A successful phishing campaign against that configuration yields immediate production access. Dropbox's layered architecture, which might have looked like unnecessary process overhead in a greenfield design review, contained the blast radius.
The attacker did obtain some credentials, including API keys used by internal services and copies of credentials that had been committed and not subsequently rotated. Dropbox's cleanup included rotating those credentials and beginning a program to reduce secret sprawl in repositories. The company also disclosed that some of the compromised repositories contained personally identifiable information for Dropbox employees and some customers and vendors, which triggered regulatory notifications.
Three supply chain lessons
Phishing pretexts move up the toolchain. In 2015, corporate phishing pretexts centered on HR and finance. In 2022, they centered on the developer toolchain. The transition reflects a realistic attacker assessment: the highest-leverage credentials in a modern company often sit with engineers, who have access to source, build pipelines, and deployment systems. CircleCI, GitHub, npm, PyPI, Vercel, Netlify, and Docker Hub have all appeared in phishing pretexts since 2020. A security awareness program tuned to "beware of HR impersonation" misses the actual pressure on the developer inbox.
Phishing-resistant authentication is no longer optional for engineers. Dropbox's incident post explicitly acknowledged that the compromised account used TOTP rather than a hardware security key. Reverse-proxy phishing kits defeat TOTP by design; the attacker relays the code in real time. FIDO2 and WebAuthn, with origin-bound credentials, break reverse-proxy phishing because the credential refuses to operate against a lookalike origin. An engineering organization that has not rolled out phishing-resistant authentication for GitHub, CI, and cloud consoles is running on residual goodwill from the attackers.
CI is a supply chain tier. Before 2022, "software supply chain security" in most practitioners' minds meant "package dependencies." After Dropbox and CircleCI, it also means "the CI system that builds the package." A compromised CI account can publish a malicious artifact, exfiltrate secrets, modify deployment manifests, and register persistent webhooks, all within the normal behavior of the CI role. Treating CI as part of the supply chain means applying the same vendor scrutiny, the same least-privilege controls, and the same monitoring coverage.
What Dropbox did well
Two aspects of Dropbox's response warrant attention. The disclosure, issued twelve days after detection, was detailed, technically specific, and honest about what was and was not known. It named the pretext, described the authentication weakness, and outlined the remediation. The transparency was unusual and valuable: it gave other engineering organizations concrete information with which to audit their own exposure.
The architectural separation between development and production repositories, evidently maintained before the incident, contained what could have been a much larger event. The separation is unglamorous. It adds friction. It requires enforcement. In the post-incident reckoning, it paid for every hour of that friction many times over.
How Safeguard Helps
Safeguard helps organizations treat CI and code-hosting vendors as first-class supply chain participants rather than peripheral tools. The platform inventories the GitHub, GitLab, and CI integrations that ship credentials into build pipelines, flags long-lived secrets committed to repositories, and surfaces the blast radius a compromised CI identity would have across deployment targets. Teams can model vendor phishing scenarios, for example a CircleCI-themed lure, by querying which engineers hold which integration scopes and what a compromised session would reach. Continuous monitoring of SCM webhooks, workflow changes, and secret exposures feeds into the same prioritization model used for dependency findings. The result is a coherent view of the developer toolchain as a unified attack surface rather than a patchwork of siloed integrations.