The new supply chain blast radius

Modern supply chain incidents turn trusted software into a real-time vendor, identity, and access challenge. Continuous monitoring matters more than ever.

‍

What TeamPCP showed us

In March 2026, a single GitHub token that someone forgot to fully rotate at Aqua Security became the entry point for the most cascading supply chain campaign of the year.

‍

Here’s what happened:

‍

• Within 48 hours, the threat group TeamPCP had force-pushed malicious commits to 76 of 77 version tags of Aqua's Trivy GitHub Action. 
• They used the credentials harvested there to break into Checkmarx, poisoning all 35 version tags of the KICS GitHub Action and Checkmarx's AST action. 
• The npm tokens those compromises produced were recycled into the Bitwarden CLI hijack. 
• By mid-May, OpenAI disclosed that two employee devices had been hit through a malicious TanStack package and that code-signing certificates for macOS, Windows, iOS, and Android had been exfiltrated. 
• Days later, GitHub confirmed that a poisoned VS Code extension on an employee device had led to the exfiltration of roughly 3,800 internal repositories. 
• In the very same week, a massive account takeover of Alibaba’s @antv npm ecosystem triggered an automated token harvest allowing attackers to rapidly jump ecosystems. 
• Within less than 15 hours, TeamPCP weaponized those stolen developer credentials to compromise Microsoft's official durabletask Python SDK on PyPI.

‍

Their worm—Mini Shai-Hulud—spread across npm and PyPI, eventually compromising more than 170 packages with 518 million cumulative downloads. This massive, global chain of compromise didn’t start with a sophisticated heist. It all began six weeks earlier, with one missed credential rotation at a much smaller vendor.

‍

This is the new shape of supply chain risk. It’s not one breach, one vendor, one customer. It’s a cascade.

‍

Developer environments provide access, AI amplifies the blast radius

A few years ago, a compromised developer workstation was dangerous, but its reach was limited: Source code, SSH keys, and maybe some staging access.

‍

That picture no longer holds. A single developer environment now reaches into GitHub, CI/CD pipelines, SaaS admin panels, MCP servers, and more, often in the same session and sometimes through the same automation. AI coding tools and MCP-style integrations are normalizing this. The same access patterns that make those workflows powerful also make supply-chain compromise more dangerous. A credential or token stolen from one of these environments now opens more doors, faster, than it ever has.

‍

The TeamPCP campaign worked because every poisoned package was also a credential collection point, and every stolen credential became the next distribution channel. 

‍

The security industry is still learning what to do about this. There is no settled playbook yet. What is clear is that the old model—point-in-time vendor reviews and quarterly access audits— was strained even before AI-era workflows pushed it past its limits. A vendor that was safe at procurement can become risky the day after approval. In a static review model, trust is granted at a point in time. In a modern model, trust can change overnight. It needs to keep moving as the vendor's posture moves.

‍

The early warning and the access reality behind it

In a fast-moving supply-chain incident, the first advantage is awareness. Knowing about an incident earlier—before the disclosure email, the news article, or the next reassessment cycle—is what gives a security team time to do something useful.

‍

That is what Vanta's Continuous Monitoring is built for. It takes a threat-feed approach to third-party risk: Continuously assess what is visible from the outside, enrich it with threat intelligence and exploitability data, and prioritize the signals that actually matter. 

‍

Because the underlying intelligence varies in strength, Continuous Monitoring uses three levels of confidence, and every signal is validated by hand by our research team before it reaches the customer:

‍

• Potential incident signal. Our intelligence suggests a vendor may be involved in a security incident. This is the cue to do an internal risk assessment to ensure the vendor's inherent risk is mapped to the apps it actually touches, so you can respond in a way that fits your risk appetite. Vanta supports the full range.
• Suspected incident signal. This is an incident that has been widely reported by reputable third parties (news articles, threat analysis groups), but has not yet been confirmed by the vendor.
• Confirmed incident signal. This is a security incident that’s been confirmed by the vendor.

‍

The various levels exist on purpose. Early intel gives a customer time to prepare; confirmed intel gives them the certainty to act. During the TeamPCP campaign, Vanta customers monitoring GitHub, OpenAI, Microsoft, and other affected npm publishers received alerts within hours of those disclosures—not two weeks later in a magazine and not after a developer's stolen token surfaced on the dark web.

‍

An early risk signal is useless if you can't act on it. All the pieces—vendor data, app integrations, user accounts—are usually scattered, and trying to manually stitch that picture together during an incident slows response down. Vanta closes this gap by connecting vendors directly to the apps where access actually lives, giving you a single view of the vendor's risk, security status, and every account that might be exposed.

‍

From signal to action

Once a vendor signal is tied to real exposure, Vanta helps teams move through a clear, repeatable workflow:

‍

1. Detect the signal. Continuous Monitoring surfaces a potential or confirmed incident risk change on a vendor.
2. Confirm the scope. The alert only fires for vendors already in inventory—all that’s left is to make sure inherent risk is up to date and that the vendor is correctly mapped to the apps it touches.
3. Understand the access footprint. See every account in the affected app, integrated and manual, in one place.
4. Prioritize the response. Use vendor risk score, last review date, app ownership, account count, and business criticality to determine urgency.
5. Trigger an access review. Kick off a review on the impacted app. The approver assigned to that app becomes the default reviewer.
6. Recommend access removal. Route deprovisioning work to the app admin where access is no longer justified.
7. Preserve evidence. Keep a record of what was reviewed, who reviewed it, what changed, and how the organization responded.

‍

How security leaders should respond

The shape of the supply-chain problem has changed. In the AI era, the most dangerous incidents are no longer just code problems—they are vendor, identity, access, and data-governance problems moving at machine speed.

‍

In the next vendor incident, the questions that matter, like who owns this vendor, which apps are connected, what data is exposed, who has access, when was it last reviewed, what evidence exists that we acted, are the same questions a control framework is supposed to answer. The difference is timing. Continuous controls and continuous evidence give a team a repeatable workflow, even when a call comes in afterhours. 

‍

Supply chain risk used to be reviewed once at procurement. Now, it must be monitored continuously. When a vendor or workflow is compromised, your response speed depends entirely on knowing which apps are connected, who has access, and what actions to take.

‍

Vanta connects that signal directly to the workflows that reduce downstream impact: Vendor risk signal → Vendor context → App footprint → Account exposure → Access review → Deprovisioning → Evidence.

‍

Learn more about Vanta’s Third Party Risk Management solution here.