Supply Chain Poisoning: AI helps you write code, but also installs malicious packages—who is keeping guard?

First, let's start with a question: the last time you used AI to write code, did you check which third-party packages it installed for you?

The odds are that you didn't.

Using tools like Claude Code and Cursor today, you typically just state your requirements, and within seconds, the AI writes the code, installs the dependencies, runs it, and shows you the result. It is incredibly smooth.

All you care about is getting a working result. As for what got installed in the process and whether those packages are safe, checking them one by one probably never crossed your mind.

This new habit has multiplied efficiency several times over. But it has also quietly changed one crucial thing: the decision-making power of installing packages has shifted from humans to AI.

And the risk of this shift was recently proven by a real-world incident.

Shai-Hulud: A Self-Replicating Poison

On May 25, China's National Computer Network and Information Security Information Center issued an alert: npm, the world's largest JavaScript package platform, was poisoned by a malware program named "Shai-Hulud" (Sandworm).

Attackers compromised official maintainer accounts and injected over 600 infected versions across more than 300 independent packages.

The most troublesome aspect of Shai-Hulud is its ability to self-replicate.

Once it steals a developer's publishing credentials, it automatically injects malicious code into other packages maintained by that developer and publishes new versions.

Whoever installs it downstream will have their credentials stolen. GitHub Tokens, cloud keys, SSH private keys, and database passwords are all compromised in one go, and the malware continues to crawl outward from that machine.

Its spread did not stop at npm. Forty-two packages from echarts-for-react, the @antv series, and TanStack were compromised, and the infection even spread to the Python ecosystem.

Even the official Python SDK on PyPI for Mistral AI, a leading French large language model company, was injected with malicious code.

In other words, frontend developers, AI developers, and open-source maintainers are all in the line of fire.

Now, let's look at these two things together: a self-replicating, credential-stealing poison meets an AI with the freedom to install packages at will.

Has AI magnified the risk?

In the past, when installing a package, a human would naturally hesitate: Is this maintainer reliable? Has it been updated recently?

Though not rigorous, this hesitation served as a brake.

AI auto-installation has removed this brake.

A deeper issue is that the skills, plugins, and extensions used by AI programming tools themselves are also "packages" and can be poisoned too.

This means the risk lies not only in the business dependencies the AI installs for you, but also in what the AI tools install for themselves.

This is a brand-new attack surface that traditional software supply chain protection has barely touched.

How large is this surface? Here is a number to give you a sense: on major AI skills platforms, the proportion of malicious skills is as high as 30.28%.

Yet, many people using AI tools have no idea which skills have been installed, let alone which skills might be problematic.

Efficiency and risk are two sides of the same coin here.

While AI has made "acquiring capabilities" easier, it has also made "introducing risks" just as easy.

You might say that your company has private repositories and schedules regular scans.

These two are indeed fundamental, but they lag behind in the AI era in two key aspects.

First, timing.

Private repositories are only responsible for storing packages and do not guarantee they are clean. SCA scanning is periodic, meaning malicious packages installed between scans would have already exfiltrated data long before. Both are reactive "after-the-fact" measures.

Second, scope.

They mostly recognize traditional code packages and fail to identify new formats like AI skills and plugins. They are blind to the entire layer of attack surface introduced in the AI era.

A worm like Shai-Hulud does not discriminate; it crawls along the dependency chain and enters whoever's door is left unlocked.

Large companies have the processes and budget to handle this, but most small and medium-sized teams are running completely unprotected. It's not that they don't know the risks; they simply lack the manpower and budget.

Ultimately, threat intelligence is not lacking today. When a package has an issue, intelligence is quickly published.

What we lack is the gate between threat intelligence and blocking. You might know a package is poisoned, but you have nothing to block it the exact moment it tries to land.

Move the Checkpoint to the "Entryway"

We can change our approach. Instead of waiting for packages to enter, scanning them repeatedly, and deleting them after an incident, it's better to block them at the very moment they arrive at the door.

This is exactly what the SecXin Software Supply Chain Anti-Poisoning Intelligent Gateway does.

Positioned between you and external packages, it acts as a proxy for artifact repositories. Every incoming package goes through an intelligence check first:

1. If it matches a known malicious package, block it immediately;

2. If it is on the whitelist, allow it through directly;

3. If it is unrecognized, perform a real-time cloud query.

It takes less than 5 milliseconds locally and under 2 seconds in the cloud, barely interrupting the development workflow.

Crucially, the three entry points it monitors are exactly the pain points of the AI era: local developer workstations, CI/CD pipelines, and AI programming assistants.

And it truly manages AI. Its underlying threat database contains over 450,000 records covering both traditional packages and AI skills, currently monitoring 710,000 AI skills across four major AI skills platforms.

It takes an average of 6 hours from threat detection to rule push. It features one-click Docker deployment and goes online in half an hour without changing any developer habits.

AI-assisted coding and AI-driven package installation are trends that will not, and do not need to, be reversed—they make things much faster.

But one thing must be clear: AI can write and install for you, but it cannot take responsibility for you. If a package is poisoned, credentials are stolen, and data is breached, the blame still falls on you and your company.

The manual quality control that has been bypassed must be replaced by something else. As AI speeds up development, putting a gate on this accelerated workflow is no longer optional.

The next time AI installs a package for you, do you want it to come straight in, or would you prefer it to be checked at the door first?

When you use AI to write code, how do you manage the package installation step? Do you still install whatever the AI recommends? Let's discuss in the comments section, and feel free to share this with colleagues who might be dealing with this headache.

Reference: Notification from the National Computer Network and Information Security Information Center: Major JavaScript package management platform npm hit by supply chain poisoning attack, Cybersecurity Bureau of the Ministry of Public Security, May 25, 2025