If you run a small or mid-sized business that depends on software (so, all of you), the last six months should have your attention. A hacking group called TeamPCP has been running one of the most aggressive software supply chain attack campaigns we've seen, and the way they're doing it should change how you think about the tools your team installs.
This isn't a theoretical risk. GitHub itself confirmed a breach last week. So did Grafana, OpenAI, and the European Commission. The attack has touched hundreds of organisations so far, and it's still going.
Even if you've never heard of npm or CI/CD, this one matters. And there are things you can do about it that don't require a Fortune 500 security budget.
What TeamPCP Actually Did
TeamPCP first appeared in late 2025. Their method is simple in concept and brutal in execution: they compromise a tool that developers trust, plant credential-stealing malware inside it, harvest the stolen credentials, and then use those credentials to poison more tools. Rinse, repeat, scale.
The group started by exploiting Aqua Security's Trivy vulnerability scanner, a tool used by over 10,000 development teams to check their code for security problems. That's the part that should make you uncomfortable. The security tool was the attack vector.
From there, they moved across ecosystems: GitHub Actions, Docker Hub, PyPI (Python packages), npm (JavaScript packages), VS Code extensions. Socket, a software supply chain security firm, counted over 20 attack waves and more than 500 compromised software packages. Palo Alto's Unit 42 reported that attackers had already exfiltrated over 300 GB of data and secrets from 500,000 machines by April.
Their latest move was compromising GitHub's own internal repositories. According to GitHub's statement, attackers got in after an employee installed a malicious VS Code extension. The group claimed access to roughly 3,800 internal repos, and GitHub said that number was "directionally consistent" with their investigation findings.
The campaign includes a self-replicating worm they call "Mini Shai-Hulud" (a Dune reference). It automates the cycle: steal credentials from a CI/CD pipeline, use them to publish poisoned package versions, and spread further. In one documented wave, 28 packages were compromised in under 60 seconds.
We covered an earlier wave of this campaign in detail when TanStack packages were compromised in May. That post is worth reading alongside this one.
Why This Matters If You're Not a Developer
Here's the thing most coverage misses: you don't need to be a software company to be affected.
The accounting platform you log into every morning, your CRM, the cloud your website runs on: all of it is built on open-source packages. Layers and layers of them. When one of those packages gets poisoned, the malware rides into your environment inside a routine software update that looks completely normal.
The TanStack attack is a good example. The compromised npm packages carried valid SLSA Build Level 3 provenance attestations. In plain language: the malicious versions passed the security checks designed to prove they were legitimate. Your developer, your IT provider, or your automated pipeline would have had no obvious reason to reject them.
TeamPCP specifically targeted SDKs for billing, insurance, and accounting services to maximise their chances of landing in high-privilege corporate environments. If your business runs software that touches financial data (and it does), this kind of attack is aimed squarely at you.
What SMBs Can Actually Do About This
We're not going to tell you to "implement zero trust across your entire software supply chain." You have 15 employees and one IT person who also manages the printers. Here's what's practical.
Know what software your business actually runs.
You can't protect what you can't see. Most SMBs have no idea how many third-party tools, plugins, browser extensions, and cloud services are running across their environment. Start with an inventory. It doesn't need to be fancy. A spreadsheet of every tool, who uses it, and whether it auto-updates is a real starting point.
If you work with a development team or IT provider, ask them for a Software Bill of Materials (SBOM) for anything they build or maintain for you. An SBOM lists every dependency in a piece of software, which is exactly how you'd spot a compromised package like the ones TeamPCP poisoned.
Put a delay on non-security updates.
This is counterintuitive because we've been told for years to update everything immediately. Security patches: yes, apply those fast. But for feature updates and new versions of development tools, a 48 to 72 hour delay gives the security community time to catch compromised packages before they hit your systems.
Risk Ledger's analysis of the TeamPCP campaign specifically recommended quarantining non-security dependency updates for this reason. The poisoned packages were almost always caught within days, but organisations that auto-updated on release day were already exposed.
Lock down your CI/CD pipelines (or make sure your IT provider does).
If your business has any custom software, internal tools, or automated deployment processes, this applies to you.
Pin GitHub Actions and dependencies to specific commit hashes, not version tags. TeamPCP's attack on Trivy worked because they force-pushed malicious code to existing version tags. If you referenced trivy-action@v1, you got the poisoned version. If you referenced a specific commit SHA, you didn't.
Restrict what secrets your build pipelines can access. The SANS Institute's analysis of this campaign noted that over-permissioned CI/CD environments were the primary enabler of the cascading credential theft. Each pipeline should only have access to the credentials it actually needs.
Rotate secrets regularly, and rotate them immediately if there's any indication of a compromise in your toolchain. UltraViolet Cyber's threat advisory made the point that defensive tooling needs to be held to the same integrity standards as production software, because a compromise at that layer silently affects everything downstream.
Vet your VS Code extensions and developer tools.
The GitHub breach happened because of a malicious VS Code extension. Extensions are code running on your developers' machines with access to whatever those machines can reach.
Limit which extensions your team can install. Review extensions before approving them. If an extension is new, has few downloads, or was recently transferred to a new publisher, treat it with suspicion. The same goes for any IDE plugin or developer tool.
Audit your third-party vendors.
Your IT provider, your managed service provider, your SaaS vendors: ask them what they're doing about supply chain security. Specifically:
- Do they generate SBOMs for the software they build or manage?
- Do they pin dependencies to commit hashes?
- How quickly do they rotate credentials after a reported supply chain compromise?
- Do they have a process for vetting open-source dependencies before adopting them?
If they can't answer these questions clearly, that's useful information. According to the Verizon 2025 DBIR, third-party involvement in breaches doubled in a single year, going from 15% to 30% of all breaches analysed.
Train your team on what "trusted" software actually means.
The old model was: if it's a known tool from a known source, it's safe. TeamPCP broke that model. Trivy was a known tool from a known source. The TanStack packages passed cryptographic verification. The VS Code extension that got into GitHub looked like a legitimate extension.
Your team needs to understand that trusted doesn't mean permanently safe. Updates should be treated with a degree of scepticism, unusual behaviour after an update should be reported immediately, and nobody should install developer tools or extensions without review.
The Bigger Picture for Australian SMBs
Australia's cybersecurity regulatory environment is tightening. Between the updated Security of Critical Infrastructure Act, Privacy Act reforms, and APRA's CPS 234, the direction is clear: businesses are expected to understand and manage their supply chain risk, not just their own perimeter.
Accounting firms, financial advisers, and SMSF administrators are in a tough spot here. You hold sensitive financial data. You rely on software ecosystems that are exactly the type TeamPCP targets. And your clients assume you've got this covered.
You can't eliminate supply chain risk entirely. No one can. GitHub, the platform that hosts the world's code, got breached through this campaign. But you can shrink your exposure and have a plan for when something gets through.
For a broader look at how Zero Trust principles apply to businesses your size, see Zero Trust for SMBs: A Practical Implementation Guide.
Where to Start
If you're reading this and thinking "we should probably look at this," you're right. Start with the inventory. Then talk to whoever manages your IT about dependency pinning and SBOM generation. Ask when secrets were last rotated. That conversation alone will tell you a lot about where you stand.
If you want help working through this for your specific setup, that's what we do at OrionX. We work with Australian SMBs to audit their software supply chains, harden their CI/CD pipelines, and put practical security controls in place. Not theoretical frameworks. Actual changes that reduce your exposure.
Get in touch if you want to talk through your situation.
