The Invisible Threat Inside Your Dependency Tree

Your code review process works fine for human-written code. Team members read the logic. They spot edge cases. They catch bugs. Then you merge, deploy, and move on.

But what happens when an AI assistant writes part of your code? Specifically, what happens when it invents a package name that doesn't exist yet, and you accidentally install it before anyone notices?

This is no longer theoretical. Developers using Claude, Copilot, and other coding agents are generating fictitious dependency names at scale. The AI models hallucinate packages confidently and idiomatically. They're so plausible that humans miss them. They're so common that attackers are already registering the packages and waiting.

How the Attack Actually Works

When you ask an AI to scaffold a backend service or add a feature, the model generates code including imports and package declarations. Sometimes it references packages that sound real but don't exist. The generated code looks correct. It passes basic syntax checks. The import statement reads naturally.

You run npm install or pip install and nothing breaks. The package registry returns a result. Installation succeeds. The postinstall script runs with your full permissions. Days or weeks later, you discover the package was malicious.

This attack vector exists because AI agents fundamentally operate differently than human developers. A human knows which packages exist in their ecosystem. An AI model trained on thousands of repositories generates statistically likely package names without verifying they're real.

Why Traditional Security Checks Miss This Entirely

You probably run npm audit or use a vulnerability scanner. These tools check installed packages against known vulnerability databases. They work great for catching exploited libraries.

They fail catastrophically here. The malicious package doesn't exist in any vulnerability database yet. It's brand new. It's never been seen before. The security tools have no signal to detect it.

Furthermore, dependency auditing happens after installation. By that time, the postinstall hook already executed. Malware already ran. You already have the problem.

Additionally, code review doesn't help. Reviewers ask "is this code correct?" They don't ask "why does this package exist?" or "has this ever been used in production?" Those are provenance questions. They require a different mental model.

The Gap in Your Current Workflow

Most indie developers and small teams don't have a separate approval process for dependency changes. A PR that adds a feature also adds dependencies. It all flows through the same review gate. This worked fine before AI agents started writing package.json files.

Now, you need a different approach. Dependencies are trust decisions, not code changes. They deserve separate scrutiny.

What You Should Be Checking Right Now

Stop waiting for `npm audit` to catch new vulnerabilities. Start checking three things at install time.

1. Does the Package Actually Exist and Have History?

When an agent introduces a new dependency, verify it on the registry immediately. Don't just check if it exists. Check when it was created. How many releases? How many downloads? Does it have a GitHub link? Is the maintainer established?

Real, trustworthy packages have history. They've been around. They have multiple releases. They have users. A package created yesterday with one version and zero downloads is suspicious.

Tools like Postman API Platform can help you document and verify API dependencies, but for npm specifically, you need to check the registry directly before install.

2. Is the Package Name Similar to Something Else?

Typosquatting attacks work because names are close but not identical. `reqeusts` instead of `requests`. `cross-evn` instead of `cross-env`. AI agents can generate names that are one or two characters away from real packages.

Create a simple edit-distance check. When a new dependency appears in your manifest, compare it against a whitelist of legitimate packages in your ecosystem. Flag anything that's suspiciously similar but not exact.

Here's a quick Node.js function to detect this:

function levenshteinDistance(a, b) {
  const matrix = Array(b.length + 1).fill(null).map(() =>
    Array(a.length + 1).fill(0)
  );
  for (let i = 0; i <= a.length; i++) matrix[i][0] = i;
  for (let j = 0; j <= b.length; j++) matrix[0][j] = j;
  for (let i = 1; i <= b.length; i++) {
    for (let j = 1; j <= a.length; j++) {
      const cost = a[j, 1] === b[i, 1] ? 0 : 1;
      matrix[i][j] = Math.min(
        matrix[i, 1][j] + 1,
        matrix[i][j, 1] + 1,
        matrix[i, 1][j, 1] + cost
      );
    }
  }
  return matrix[b.length][a.length];
}

const distance = levenshteinDistance('lodash', 'loadash');
if (distance <= 2) console.log('SUSPICIOUS MATCH');

A distance of 2 or less indicates a potential typosquat. Flag it for review.

3. Which Agent Introduced This Dependency?

When something does get compromised, attribution matters. You need to know which AI tool, which prompt, which session introduced the malicious package. Was it Claude? Copilot? A custom agent?

This information lets you trace the damage. Did the agent introduce similar packages elsewhere? Did the same prompt generate other suspicious code? Did this happen in other projects?

Add metadata to your commits. When an AI modifies package.json, include the tool name, timestamp, and prompt in the commit message or a supplementary log file. Store this in a way you can query later.

Building a Practical Defense Today

You don't need to wait for a comprehensive tool. You can implement these checks now with a pre-commit hook.

A Pre-Commit Hook That Actually Works

Create a .git/hooks/pre-commit file (or use Husky to manage it):

#!/bin/bash

# Check if package.json was modified
if git diff --cached --name-only | grep -q 'package.json\|requirements.txt'; then
  echo "Checking new dependencies..."
  
  # Extract new packages from git diff
  NEW_PACKAGES=$(git diff --cached package.json | grep '^+' | grep -oP '"\K[^"]+' || true)
  
  for pkg in $NEW_PACKAGES; do
    # Query npm registry
    RESPONSE=$(curl -s "https://registry.npmjs.org/$pkg")
    
    if echo "$RESPONSE" | grep -q '404'; then
      echo "ERROR: Package '$pkg' not found on npm registry"
      exit 1
    fi
    
    # Check if package is suspiciously new
    TIME=$(echo "$RESPONSE" | grep -oP '"time":\{[^}]*"published":"\K[^"]+' | head -1)
    if [[ ! -z "$TIME" ]]; then
      CREATED=$(echo "$RESPONSE" | grep -oP '"created":"\K[^"]+' | head -1)
      if [[ -z "$CREATED" ]]; then
        echo "WARNING: Cannot verify creation date for '$pkg'"
        read -p "Continue anyway? (y/n) " -n 1 -r
        [[ ! $REPLY =~ ^[Yy]$ ]] && exit 1
      fi
    fi
  done
fi

exit 0

This hook blocks commits if new packages don't exist on the registry. It runs before code reaches your repository.

The Broader Shift You're Missing

This isn't just a security problem. It's a process problem. The way you review code needs to change because the way code is written has changed.

In contrast to traditional code review, dependency review requires different expertise. It's not about understanding logic. It's about understanding supply chains, package ecosystems, and threat models.

As a result, many teams are starting to separate these concerns. Code changes go through one approval path. Dependency changes go through another. The second path involves different people asking different questions.

For solo developers, this means you need a personal checklist. Before merging any AI-generated code, specifically verify new packages separately from everything else.

Questions to Ask When Adding Dependencies

Is this package on the official registry (npm, PyPI, etc.)?
When was this package first published? (Anything created in the last 30 days is worth investigating.)
Does the package have documentation outside the registry? (A GitHub repo, an official website.)
Does the package have more than one release? (Single-version packages are suspicious.)
Did a human write this package name, or did the AI generate it?

These questions take 5 minutes to answer. They catch the vast majority of problems.

Tools and Workflows to Implement Today

You can build this defense yourself, but several approaches already exist. Additionally, some of these integrate with your existing development workflow.

First, use a online markdown editor to document your dependency approval process. Write down the exact steps you take when adding new packages. Share this with collaborators or reference it yourself.

Second, consider using a lock file strategy. Modern npm and Python projects support lock files that pin exact versions. Use them. They give you a checkpoint. When a lock file changes unexpectedly, it's easier to notice.

Third, integrate package verification into your CI pipeline, not just locally. Add a step that checks package metadata before installation. This catches problems that slip past local checks.

Finally, if you're working with a team, use a Swagger specification to document your approved dependencies and their purposes. This creates a reference point.

What Happens When You Don't Act

The malware scenario is real, but it's not the only risk. Even legitimate packages with poor security practices become vulnerabilities when added carelessly.

An AI might add a package that works fine today but hasn't been updated in three years. It might recommend a package with a known vulnerability because the training data is outdated. It might suggest a package that's popular but has a permissive license incompatible with your project.

None of these are dramatic attacks. They're maintenance problems. But they compound over time. Six months in, you have 30 dependencies you don't fully understand. Upgrading becomes risky. Security updates require careful testing. Your project accumulates technical debt.

The defense is simple: understand your dependencies. Don't let AI agents add them without verification. It takes five minutes per dependency. It saves weeks of debugging later.

The Path Forward for Indie Developers

You probably use AI coding assistants because they're productive. They solve problems faster than writing from scratch. You should keep using them. Just change one thing: treat dependency changes as a separate decision from code changes.

Meanwhile, the broader ecosystem is slowly catching up. Some frameworks and tools are starting to verify dependencies automatically. But you can't rely on that yet. You need to do it yourself.

In the meantime, start here:

Add a pre-commit hook that blocks commits if packages don't exist on the registry.
Create a simple document listing your approved dependencies and why you use them.
When an AI suggests a new package, spend 5 minutes verifying it before adding it to your manifest.
Track which tool introduced each dependency so you can trace problems if they occur.

These practices take minimal time. They prevent the majority of supply-chain attacks. They also force you to understand your dependencies better, which is always a win.

For more on securing your development pipeline, check out Microservices.io for architectural patterns that reduce blast radius, or Hugging Face documentation if you're building custom AI tools for your team.

The security model for AI-assisted development is still being figured out. But you don't need to wait for perfect solutions. Act now with the tools and practices available today. Your future self will thank you when you don't have to debug a compromised supply chain.