Vibe Coding and Supply Chain Risk: A Developer's Checklist

AI coding assistants introduce supply chain risk by suggesting outdated or typosquatted packages. Use this checklist to audit AI-chosen dependencies before shipping.

The Dependency Problem with Vibe Coding

Microsoft recently suspended developer accounts for several high-profile open source projects without warning, blocking security patch releases for days. The incident is a stark reminder that the supply chain you depend on can break in ways that have nothing to do with the code itself.

When developers use AI assistants to scaffold projects quickly, the supply chain problem compounds. LLMs suggest packages based on training data that may be one to two years out of date. They cannot know which packages have been abandoned, typosquatted, or taken over by malicious actors since their training cutoff.

The Astral team recently published an analysis of open source security practices that reinforces this: knowing a package exists is not the same as knowing it is currently safe to use.

What AI Assistants Get Wrong About Dependencies

Outdated version pinning. LLMs will suggest specific version ranges based on what was popular during training. Those versions may now have known CVEs.


// What the LLM suggests (potentially outdated)
{
  "dependencies": {
    "axios": "^0.21.1",
    "lodash": "^4.17.15"
  }
}

Axios 0.21.1 has a known SSRF vulnerability (CVE-2020-28168). Lodash 4.17.15 has prototype pollution issues. Both have patches in later versions, but the LLM is frozen in time.

Typosquatting targets. AI assistants occasionally suggest package names with subtle misspellings, particularly for less-common packages. Always verify the exact package name against the registry.


# Verify before installing
npm view <package-name> --json | grep -E '"name"|"version"|"dist.integrity"'

Abandoned packages. LLMs do not track GitHub activity or npm deprecation notices. A package that was the standard choice two years ago may now be archived.

The Pre-Ship Dependency Checklist

Step 1: Audit what was installed


# Node
npm audit --audit-level=moderate

# Python
pip-audit

# Rust
cargo audit

Step 2: Check for outdated versions


npm outdated
pip list --outdated

Step 3: Verify package health

For each dependency the LLM introduced, check:

Last published date on the registry
Number of weekly downloads (sudden drops signal something is wrong)
Whether the maintainer's account shows any unusual recent activity

Step 4: Lock your lockfile and verify integrity


# Verify package integrity hashes haven't changed
npm ci --frozen-lockfile
pip install --require-hashes -r requirements.txt

Step 5: Set up continuous scanning

One-time audits are not enough. Dependencies that are safe today can be compromised tomorrow through account takeover or malicious updates. Automated scanning on every pull request catches this.

The Business Case for Dependency Hygiene

A single compromised dependency can give attackers access to your entire build pipeline, your CI environment, and every secret stored there. The cost of a supply chain breach, in incident response, customer notification, and potential regulatory fines, vastly exceeds the cost of automated scanning.

Key Takeaways

AI assistants suggest dependencies based on training data that may be significantly out of date; always run npm audit or pip-audit on any AI-scaffolded project before shipping.
Version numbers suggested by LLMs often correspond to releases with known CVEs that have since been patched: verify against current registry data, not the LLM's memory.
Continuous dependency scanning, not just one-time audits, is necessary because packages that are safe at install time can be compromised through maintainer account takeover after the fact.