The route
An employee installed what looked like a familiar extension for a widely used code editor. It was a trojanised copy. From the employee’s machine, attackers reached around 3,800 of the company’s internal repositories before the compromise was detected and contained; the extension was removed from the marketplace, the device isolated, incident response begun. The company said it had no evidence that customer repositories were touched, and linked the intrusion to a supply-chain campaign that had already compromised a well-known open-source project through the package registry.
The group claiming responsibility offered the repositories for sale rather than demanding a ransom — the same group previously linked to attacks on package registries and container hubs, and to a campaign that reached staff at a leading model provider. Around it, the wider pattern: a compression utility, a vulnerability scanner and more than five hundred registry packages compromised in two years; extensions with nine million combined installs pulled from the marketplace for security risks; two dozen crypto-stealing extensions from one actor; and, this January, two extensions marketed as AI coding assistants, with a million and a half installs between them, exfiltrating data from developer machines.
The company has not said what the 3,800 repositories contained. From outside, nobody can. Which is the point: the value of a repository breach is decided by what was committed to it, and organisations rarely know.
Why this is a data-platform story
Developers are the most privileged users of most data estates, and their tooling is the least governed. A developer’s machine typically holds credentials to the warehouse, the pipelines, the cloud accounts and the deployment environment. Their repositories typically contain — despite every policy — connection strings, service-account keys, configuration files with secrets in them, and the infrastructure definitions that describe exactly how the data platform is put together. An attacker who owns a developer’s editor owns all of that, without touching the warehouse’s own controls.
AI coding assistants sharpen the problem. They are extensions. They run with the developer’s privileges, they read the entire codebase to be useful, and by design they send what they read somewhere. The two malicious “assistants” pulled from the marketplace in January were doing what a legitimate assistant also does — reading code and transmitting it — with a different destination. Distinguishing the two after installation is hard. Deciding which may be installed at all is not.
The controls, which are not new
- Allow-list the tooling. Extensions, packages and AI assistants that may be installed on machines with access to production data are a finite, approved set. Everything else is refused at install, not discovered in an incident.
- No secrets in repositories. Enforce it with scanning at commit, and assume the historic ones are already exposed — rotate them. The question after a repository breach should be “what did they get?”, and the answer should be “code, and nothing that unlocks anything.”
- Short-lived, scoped credentials. A developer’s access to the warehouse should be a session, not a key: issued for the task, expiring in hours, scoped to what the task needs. A stolen credential that expires at lunchtime is a very different incident from one that lasts for years.
- Treat developer endpoints as tier-zero. If a machine can reach the data platform’s control plane, it is part of the data platform’s security boundary, and it gets the hardening, the monitoring and the allow-listing that implies. Convenience is not an argument against this; it is the reason it has been avoided.
- Know what the repositories hold. An inventory of where credentials, connection details and infrastructure definitions live is the difference between an afternoon’s rotation and a month’s uncertainty.
The pairing
This piece belongs beside an earlier one on non-production data: the copies of production data that live in development and test environments, with a fraction of production’s protection. The two are the same problem viewed from opposite ends. Non-production environments hold the data; developer machines hold the keys to it; both sit outside the controls that security actually reviews. AI is multiplying both — more copies for models to train on, more tools with privileged access to read them.
The organisation in this month’s news is one of the most security-capable in the world, and a single poisoned extension reached thousands of its repositories. The lesson is not that it was careless. It is that developer tooling is now where the attackers are, and that for a data platform, the developer’s machine is the perimeter.
