Supply Chain Attacks: What to Ask Your Web Developer

Most business websites and apps are built on top of hundreds of small open-source packages written by strangers. Last year a hacker group called TeamPCP turned that fact into a weapon: it planted malware in widely used open-source software, stole developer accounts, and used those accounts to poison more software, over and over. As reported by Ars Technica, Google's threat intelligence team had an undercover analyst inside the group's inner circle for months, and two Australians in their early twenties were arrested and charged last month as alleged key participants.

What actually happened

The group compromised a chain of well-known developer tools, among them the security scanner Trivy, the AI API tool LiteLLM, the web library TanStack, infrastructure at security firm Checkmarx, and the AI platform Mistral AI. Each compromise handed the attackers more developer credentials, which they used to poison the next tool. At times they ran a self-spreading worm, named Mini Shai-Hulud after the sandworms in Dune, to automate the cycle.

The result: more than a thousand companies breached, including code repository GitHub, data contracting firm Mercor, and employee devices at OpenAI and the European Commission. Australian police put the haul at more than half a million users' credentials. Notably, the group struggled to make money from it — Google's researcher estimates only tens of thousands of dollars in extortion payments — so it partnered with another crew, ShinyHunters, which then used the stolen credentials on its own. Google's analyst had access to the server holding the stolen credentials, and the company went to providers such as Amazon Web Services and Microsoft to get them revoked before they could be used.

One more detail worth remembering: someone in the group used an AI tool to build a zero-day exploit that bypassed two-factor authentication in a widely used piece of login software. Google obtained the code, confirmed it worked with small changes, and warned the developer, who patched it.

Why this reaches your business

You do not have to be a tech company to be in the blast radius. If your site, store, or mobile app is built with modern tools, your developer pulls in third-party code packages, and those packages pull in more. A single poisoned package in that chain runs with the same permissions as the rest of your code. It can quietly read whatever your server can read: customer records, order data, payment provider keys, CRM tokens.

The second path is accounts. Much of this campaign ran on stolen developer credentials and access tokens, not on clever exploits against the victims themselves. If the person or agency that built your site keeps a hosting password, a database key and a payment provider token in a chat thread or a personal laptop, that is your exposure, not theirs. And the 2FA detail matters: a second factor is still worth having, but it is not a guarantee.

Questions to ask your developer this month

• Do we have a list of what our project depends on? Ask for the dependency file and lockfile, and ask whether third-party packages are pinned to fixed versions rather than auto-updating to whatever was published last night.
• Who holds which credentials, and where? Hosting, domain, database, payment provider, CRM, messaging APIs. Ask for a written list of accounts, who has access, and where secrets are stored. A shared chat thread is not storage.
• Are developer and admin accounts protected with two-factor authentication, and can we revoke access in an hour? Include former contractors and anyone who left the project.
• What happens when a package we use is reported as compromised? Ask who watches for those advisories and how fast a fix ships. "Nobody, currently" is a valid answer and a useful one.
• Are our production secrets separate from test ones, and how often are they rotated? Tokens that never change are tokens that stay useful to whoever steals them.

The calm version of the lesson

This campaign ended with arrests, a mole inside the group, and one partner crew betraying another. That is a good outcome, but it was luck layered on skilled work, and it does not scale to the next group. What does scale is boring hygiene: knowing what code you depend on, knowing who holds your keys, and being able to revoke access quickly. Ask the five questions above. If your developer answers them clearly, you are in better shape than most of the thousand-plus companies that got caught in this one.