Supply-Chain Security in the AI Coding Era

TL;DR

• AI coding tools can propose packages faster than teams can review them.
• The main new risks are hallucinated package names, typosquatting, slopsquatting, blind installation, lifecycle-script execution with CI secrets, and dependency bloat.
• Treat every AI-generated install command like a third-party pull request — verify name, publisher, repository, maintenance, and scripts before installing.
• Prefer built-in platform APIs (crypto.randomUUID, fetch, URL, node:crypto) over new dependencies.
• Team rule: AI can propose code and packages; humans approve what enters the software supply chain.

Why AI changes the supply-chain problem

Modern JavaScript development moves quickly because teams build on open-source packages. Frameworks, UI components, validators, routers, database drivers, build plugins, test tools, and deployment adapters all save time.

But every package is also third-party code entering your software supply chain.

That matters more in the AI coding era. AI assistants can generate working features, suggest packages, and produce install commands in seconds. This increases development speed — but it can also introduce vulnerable, unnecessary, misspelled, outdated, or malicious dependencies faster than teams can review them.

A secure JavaScript project needs a dependency process that is deliberate, repeatable, and enforced in CI.

AI-generated suggestion or human package request
                    ↓
         Human package review
                    ↓
        Lockfile update and audit
                    ↓
        Tests and production build
                    ↓
          Reviewed merge to main

The goal is not to avoid open source or AI tools. The goal is to use both with ownership and controls.

The AI-era supply-chain risks

AI coding tools are useful collaborators, but they are not package-security authorities.

An AI tool can generate code that appears plausible while recommending:

• A package with an incorrect name
• An outdated package
• A package with a similar but malicious name
• An unnecessary package for a simple platform feature
• An install command that introduces many transitive dependencies
• Configuration copied from a project using a different ecosystem or version

A typical risky flow looks like this:

Developer asks AI to add a feature
        ↓
AI proposes code and "install this package"
        ↓
Developer runs the command without review
        ↓
New direct and transitive dependencies enter the repository
        ↓
Third-party code executes locally, in CI, or in production

Hallucinated packages

An AI can suggest a package name that does not exist. Attackers may register plausible names and wait for developers to install them.

Typosquatting

A malicious package may closely resemble a legitimate one.

real-package
reai-package
real-packages
real_package

A quick copy-paste can be enough to introduce malicious code.

Slopsquatting

Slopsquatting is a newer form of package-name targeting: attackers register names that AI models are likely to hallucinate or recommend. The package does not need to impersonate a famous package exactly; it only needs to look believable enough to be installed.

Blind installation

Generated commands can create false confidence:

# npm
npm install useful-ai-helper

# Bun
bun add useful-ai-helper

# pnpm
pnpm add useful-ai-helper

The command may be syntactically correct while the package is unreviewed, abandoned, malicious, or unnecessary.

Lifecycle scripts and CI-secret exposure

Packages can run preinstall, install, postinstall, and prepare scripts. Those scripts execute with the same privileges as the developer or CI runner installing them — meaning access to source code, environment variables, cloud credentials, and package-publishing tokens.

An AI-suggested package that "just works" locally can still exfiltrate secrets the first time it runs in CI. Review scripts before installing, and scope CI secrets to the jobs that actually need them.

Excessive dependencies

AI often optimizes for producing an answer quickly, not for minimizing your attack surface. It may recommend a package for behavior already available in the runtime.

For example:

UUID generation        → crypto.randomUUID()
URL parsing            → URL and URLSearchParams
HTTP requests          → fetch
Hashing                → node:crypto
Environment variables  → process.env

The best dependency is often the one you do not add.

Human review controls for AI-generated code

Treat an AI-generated dependency recommendation like a third-party pull request.

Before installing a package, verify:

1. Do we really need this package?
2. Is the package name correct?
3. Is the publisher expected and credible?
4. Does the package have an active source repository?
5. Is it maintained and recently released?
6. Does it run install, postinstall, or prepare scripts?
7. Can existing project code or platform APIs handle this?
8. What new transitive dependencies will it introduce?
9. Has the final lockfile been audited?

Avoid blind installation:

# Risky: copied directly from an AI response
# npm
npm install unknown-helper-package

# Bun
bun add unknown-helper-package

# pnpm
pnpm add unknown-helper-package

Prefer an inspected workflow:

# Review package metadata first
# npm
npm view <package-name> repository maintainers version

# Bun
bun pm view <package-name> repository maintainers version

# pnpm
pnpm view <package-name> repository maintainers version

# Add only after review
# npm
npm install <package-name>

# Bun
bun add <package-name>

# pnpm
pnpm add <package-name>

# Verify the resulting tree
# npm
npm audit
npm run build

# Bun
bun audit
bun run build

# pnpm
pnpm audit
pnpm run build

The team policy should be simple:

AI can propose code and packages. Humans approve what enters the software supply chain.

AI coding directive: approve, pin, audit, and remediate

Add the following directive to an AI coding assistant's project instructions. It makes dependency changes explicit instead of allowing a plausible package recommendation to become an unreviewed install.

Dependency safety rules

- Do not add, install, upgrade, remove, or replace a package unless the user explicitly approves the change.
- Prefer existing project dependencies and built-in platform APIs before proposing a new package.
- Before proposing a package, provide its exact registry name and version, publisher, source repository, maintenance status, lifecycle-script behavior, alternatives, and expected transitive-dependency impact.
- Use an exact version for every newly approved direct dependency. Do not use `latest`, `*`, `^`, or `~` for a new dependency unless the user explicitly asks for a range.
- After an approved change, update and review the lockfile, run the package-manager audit, tests, type checks, and production build.
- If the audit reports an issue, identify the dependency path and apply the narrowest reviewed fix: upgrade the direct parent, make a compatible update, or add a documented temporary override. Do not run forceful or blanket upgrades automatically.
- Report the audit result, changed package versions, lockfile changes, and verification results before considering the task complete.

Pin the approved package version

Pinning the direct dependency makes the intended version visible in package.json; the committed lockfile then pins the complete resolved dependency tree. Use the command for the package manager that owns the repository:

# npm
npm install <package-name>@<approved-version> --save-exact

# Bun
bun add <package-name>@<approved-version> --exact

# pnpm
pnpm add <package-name>@<approved-version> --save-exact

Exact pins are not a substitute for maintenance. Review and deliberately update them when a security patch is available.

Audit and fix issues deliberately

Run an audit after every dependency change and in CI:

# npm
npm audit --audit-level=high

# Bun
bun audit --audit-level=high

# pnpm
pnpm audit --audit-level=high

When an audit finds a problem, first trace the dependency path and select a safe, specific version to update. Regenerate the lockfile, rerun the audit, tests, type checks, and production build. Avoid automatic breaking fixes such as npm audit fix --force or broad update --latest commands: they can resolve one advisory while introducing incompatible or unreviewed changes.

A practical AI-assisted package approval workflow

AI proposes package
        ↓
Reviewer checks name, publisher, repo, maintenance
        ↓
Reviewer checks lifecycle scripts and transitive tree
        ↓
Reviewer decides: use platform API, use existing dep, add new package, or reject
        ↓
If added: lockfile committed, audit run, tests + build pass
        ↓
Owner recorded in PR description

Each step exists to catch a different class of failure — a hallucinated name at step 2, a malicious postinstall at step 3, an unnecessary dependency at step 4.

Dependency-minimization principles

• Prefer the platform. fetch, URL, crypto, structuredClone, and node:* cover a large share of what small utility packages provide.
• Prefer one well-maintained package over three overlapping ones.
• Remove packages that no longer have a code path importing them.
• Treat devDependencies with the same seriousness as dependencies — build tools run with your CI secrets.
• Document why each new dependency was added in the PR that introduces it.

Recommended team policy for AI-assisted development

1. Treat AI-generated package suggestions as untrusted until reviewed.
2. Never paste an AI-generated install command without inspecting the package.
3. Prefer built-in platform APIs where practical.
4. Restrict CI secrets and review lifecycle scripts before install.
5. Require a named owner for every new dependency.
6. Re-run audit, tests, and production build after every package change.
7. Remove unused dependencies during regular review — not "someday".

Closing thought

In the AI era, code can be generated faster than it can be understood. A strong dependency-review process ensures speed does not become unreviewed risk.

The operational side of this — lockfiles, audits, overrides, and CI enforcement across npm, Bun, and pnpm — is covered in the companion post: JavaScript Dependency Security: Managing Vulnerabilities with npm, Bun, and pnpm.