The New Shape of Supply-Chain Trust

One poisoned extension, one package install, one CI workflow. Any of them can now be the first domino.

That is the uncomfortable lesson from the latest Shai-Hulud activity and GitHub’s recently confirmed internal-repository breach. The scary part is not only the number of affected packages, tokens, or repositories. Counts move fast. The scarier part is where the attacker code ran: inside the trusted developer and CI path.

The modern supply chain is not just “the dependencies we ship to production.” It is your IDE, your package manager, your GitHub Actions runner, your cache keys, your OIDC flow, your local gh auth, your AI coding tool config, and the cloud account that quietly pays the bill when something goes sideways.

What happened, briefly

CISA described the original Shai-Hulud wave as a self-replicating npm worm that compromised more than 500 packages and targeted GitHub personal access tokens plus AWS, GCP, and Azure keys. GitHub later said it removed 500+ compromised packages and began pushing npm toward shorter-lived credentials, 2FA enforcement, and trusted publishing.

The later waves got more CI-aware. Instead of only stealing npm tokens from maintainers, they looked for credentials inside build environments, abused publishing workflows, and used the build system itself as distribution.

Microsoft’s May 2026 reporting on the @antv ecosystem described a “Mini Shai-Hulud” style campaign that targeted GitHub Actions environments and stole GitHub, AWS, Vault, npm, Kubernetes, and 1Password secrets. Microsoft said GitHub removed 640 malicious packages and invalidated 61,274 npm granular access tokens with write permissions and 2FA bypass.

Then GitHub confirmed an incident involving a compromised employee device and a poisoned third-party VS Code extension. GitHub said the attacker’s claim of roughly 3,800 internal repositories was “directionally consistent” with its investigation, while also saying its current assessment was exfiltration of GitHub-internal repositories only.

The Nx Console advisory gives the developer-tooling angle teeth: malicious version 18.95.0 was available for about 18 minutes in the Visual Studio Marketplace and about 36 minutes in OpenVSX. Nx later estimated roughly 6,000 VS Code activations and one Cursor activation.

Eighteen minutes was enough.

Why normal controls did not fully save us

The lesson is not “security controls are useless.” The lesson is that every control has a boundary.

Control	What it helps with	What it can miss
2FA	Account takeover	Legitimate workflow publishing malware
Provenance/OIDC	Long-lived npm tokens	Compromised build runtime
Secret scanning	Finding leaked keys	Damage before detection
Lockfiles	Version drift	Already-poisoned dependency paths

2FA helps when the attacker needs to log in as you. It helps less when malicious code runs inside a workflow that is already allowed to publish.

OIDC and trusted publishing are good. Use them. But provenance is a receipt, not a sandbox. It can prove where an artifact was built. It cannot prove that the runner, cache, script, or workflow context was clean when the build happened.

Secret scanning matters too, but it is often reactive. If a token was already copied, the clock has started.

The developer workstation is production-adjacent

Developers used to think of laptops as local machines with local risk. That model is dead.

A typical engineering workstation now aggregates source code, GitHub auth, npm credentials, cloud CLIs, database tunnels, SSH keys, package-manager caches, editor extensions, AI assistant configs, and sometimes production-adjacent environment variables. That is not “just dev.” It is a credential hub with a keyboard.

If the package ran on your laptop, assume the laptop’s reachable secrets were in scope.

Package lifecycle scripts make this worse because install-time code execution is easy to forget. IDE extensions make it worse because they run close to code and credentials. CI makes it worse because runners often hold the exact permissions attackers want: publish, deploy, fetch secrets, assume roles, and write artifacts.

That is the break. Not npm. Trust.

The vibe-coding angle

AI coding tools are not the villain here. Fast, invisible execution with broad credentials is the villain.

Vibe coding often means moving through dependencies, extensions, MCP servers, generated config, local dev servers, and shell commands quickly. That speed is useful. It is also a larger trust surface. If an agent suggests a package, installs it, edits config, and runs a script in the same environment where your cloud credentials live, you have collapsed experimentation and authority into one place.

JFrog reported Shai-Hulud-like activity targeting developer and AI-tooling configuration surfaces. Treat that as the direction of travel, not as proof that AI caused the incidents.

Vibe coding with long-lived credentials is supply-chain roulette with better autocomplete. The answer is not to stop using AI tools. The answer is to stop giving every tool the same blast radius.

Boring controls that actually work

For engineers, the practical response is operational hygiene:

Pin dependencies and commit lockfiles.
Add a release-age cooldown for new package versions where your tooling supports it.
Disable or restrict package lifecycle scripts when feasible.
Run risky installs in dev containers, Codespaces, or disposable sandboxes.
Pin GitHub Actions to commit SHAs, not floating tags.
Require signed commits on protected branches so pushed changes are cryptographically tied to trusted developer keys.
Audit pull_request_target, cache restore paths, workflow permissions, and publishing jobs.
Prefer OIDC and trusted publishing, but treat the CI runtime itself as sensitive.
Delete long-lived tokens. For the ones you cannot delete, shorten expiry and rotate automatically.
Use WebAuthn/MFA and secret scanning with push protection.
Monitor npm publishes, CI egress, cloud/API usage, and billing anomalies.
After suspected compromise: isolate hosts, rebuild runners, invalidate caches, then rotate credentials.

The best teams will not be the ones that never touch a bad package. That bar is fantasy. The best teams will be the ones where a bad package gets a tiny window, a tiny credential scope, and a loud billing or usage alert.

Proactive beats reactive because by the time you are rotating everything manually, the worm has already learned your org.