The New Shape of Supply-Chain Trust

A poisoned extension, package install, or CI workflow can be enough to start a supply-chain incident.

The latest Shai-Hulud activity and GitHub’s recently confirmed internal-repository breach show attacker code running inside developer and CI environments that already had trusted access. The exact counts of affected packages, tokens, and repositories will keep changing. The important part is the execution context.

The modern supply chain is not just “the dependencies we ship to production.” It includes IDEs, package managers, GitHub Actions runners, cache keys, OIDC flows, local gh auth, AI coding tool config, and the cloud accounts those tools can reach.

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 shows why developer tooling belongs in the threat model: 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.

Short exposure windows can still lead to real installs.

Why normal controls still have gaps

Security controls still matter, but each one only covers part of the attack path.

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 only proves where an artifact was built. It does not 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 attacker may already be using it.

The developer workstation is production-adjacent

Developers used to think of laptops as local machines with local risk. That model no longer fits how engineering environments work.

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. It often has enough access for an attacker to move into source control, package publishing, CI, or cloud accounts.

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.

The core issue is misplaced trust in environments that can execute package, extension, or workflow code with broad credentials.

The vibe-coding angle

AI coding tools did not create the underlying failure mode. The risk is rapid, low-visibility execution in environments with broad credentials.

Vibe coding often means moving through dependencies, extensions, MCP servers, generated config, local dev servers, and shell commands quickly. That speed is useful, but it increases the number of tools that can execute code near credentials. If an agent suggests a package, installs it, edits config, and runs a script in the same environment where cloud credentials are available, the experiment has access to production-adjacent authority.

JFrog reported Shai-Hulud-like activity targeting developer and AI-tooling configuration surfaces. Treat that as a warning about where attackers are looking, not as proof that AI caused the incidents.

A safer setup keeps AI tools, editor extensions, package installs, and shell commands away from credentials they do not need.

Practical controls that help

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.

Teams should not assume they can avoid every malicious package. They should limit how long untrusted code can run, restrict which credentials it can reach, and generate visible usage or billing alerts.

Preventive limits matter because manual rotation usually starts after credentials may already have been copied or used.