8 min read

Dependency scanning for AI-built apps — what to scan, what to block, what to ignore

Vibe-coded apps inherit thousands of transitive dependencies and the AI assistant invents fresh ones every prompt. This guide walks through the dependency-scanning stack for an AI-built app: what to run, what to block in CI, and how to handle slopsquatting + typosquatting + dependency confusion.

Every dependency in your package.json is a trust decision. Vibe-coded apps usually have a few hundred direct dependencies and several thousand transitive ones — far more than any human reviewed individually. Add AI-suggested package names (slopsquatting risk) and the surface gets even larger. This guide is the practical dependency-scanning playbook for an AI-built app: what to run on every PR, what to block, and how to reason about the noise.

What it is

Dependency scanning (also called Software Composition Analysis, SCA) is the systematic check of your direct + transitive dependencies for: (1) known CVEs, (2) suspicious-publisher signals (malicious-takeover heuristics), (3) hallucinated names (slopsquatting), (4) typo near-misses (typosquatting), (5) dependency-confusion attacks (private-name conflict with public registry). The output is a list of findings with severity, exploitability, and a proposed fix (upgrade / pin / remove). The challenge is signal-to-noise — naive scans ship 50+ findings a week, most non-exploitable. The right setup blocks only the findings that matter.

Vulnerable example

# Vulnerable: no dependency scanning in CI
# .github/workflows/ci.yml
name: CI
on: [push, pull_request]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm test
      - run: npm run build
# No dep-scan step. New transitive CVE published last night?
# Slopsquatting attempt in the AI-suggested install?
# Both ship to production silently.

Fixed example

# Fixed: layered dependency scanning + slopsquatting heuristic
name: CI
on: [push, pull_request]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci --ignore-scripts  # block post-install in CI

      # 1. Audit for known CVEs
      - run: npm audit --audit-level=high

      # 2. License + supply-chain integrity (Sigstore-verified)
      - uses: actions/dependency-review-action@v4
        with:
          fail-on-severity: high
          fail-on-scopes: runtime, development

      # 3. Slopsquatting heuristic - flag new packages <30 days
      #    with low downloads + no GitHub repo
      - uses: securie/dep-scan-action@v1
        with:
          slopsquat: error    # block on suspect AI-hallucinated packages
          typosquat: error    # block on typosquat near-misses
          dep-confusion: error

      # 4. Run app tests AFTER deps are validated
      - run: npm test
      - run: npm run build

How Securie catches it

Securie findingmedium
apps/web/app/api/route.ts:22

Dependency scanning for AI-built apps

Securie's dependency-vuln specialist + secret_scanner runs on every PR. For each new dependency: (1) check known-CVE database, (2) check Sigstore-verified provenance, (3) compute slopsquatting score (first-publish date < 30d + weekly-downloads < 100 + no GitHub repo + publisher mismatch = red flag), (4) compute typosquat distance against canonical packages, (5) check for dependency-confusion (private-name claimed publicly). Findings ship as PR comments with the canonical alternative + a one-tap rewrite suggestion.

Suggested fix — ready as a PR
# Fixed: layered dependency scanning + slopsquatting heuristic
name: CI
on: [push, pull_request]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci --ignore-scripts  # block post-install in CI

      # 1. Audit for known CVEs
      - run: npm audit --audit-level=high

      # 2. License + supply-chain integrity (Sigstore-verified)
      - uses: actions/dependency-review-action@v4
        with:
          fail-on-severity: high
          fail-on-scopes: runtime, development

      # 3. Slopsquatting heuristic - flag new packages <30 days
      #    with low downloads + no GitHub repo
      - uses: securie/dep-scan-action@v1
        with:
          slopsquat: error    # block on suspect AI-hallucinated packages
          typosquat: error    # block on typosquat near-misses
          dep-confusion: error

      # 4. Run app tests AFTER deps are validated
      - run: npm test
      - run: npm run build
Catch this in my repo →Securie scans every PR · ships the fix as a one-click merge · free during early access

Checklist

  • `npm audit` (or `pip-audit` / `bundler-audit`) runs on every PR with `--audit-level=high` minimum
  • GitHub Dependency Review (or equivalent) enforced as a required check
  • Slopsquatting heuristic in CI: new packages <30 days with low downloads + no GitHub repo block the merge
  • Typosquat distance check against canonical packages of the same scope
  • Dependency-confusion check on every package whose name matches a private/internal scope
  • Lockfile committed and reviewed in PRs (package-lock.json / yarn.lock / poetry.lock)
  • Production builds use `npm ci --ignore-scripts` to block post-install hooks in CI
  • Production registry is a private mirror with allow-list, not the public registry directly

FAQ

Doesn't `npm audit` cover all of this?

No. `npm audit` checks installed packages against a known-vulnerable database. It does not catch zero-day slopsquatting (the package isn't in any vuln DB until reported), typosquats (until they're reported), or dependency-confusion (registry-shape attack, not a code-level vuln).

How do I handle the noise?

Tune severity gates. Default `--audit-level=high` blocks high+critical and lets medium/low through (most are low-exploitability transitive deps). Add a quarterly review of medium-severity findings; clear the queue or pin the dep with a comment.

What about Python?

Same playbook. `pip-audit` for known CVEs; Snyk / Securie / Socket for slopsquatting + typosquat heuristics; pip's `--require-hashes` for lockfile-equivalent integrity.

Is Sigstore verification worth it?

For new builds, yes. Sigstore-verified packages have provenance you can check (signed at build time, recorded in Rekor transparency log). Maintainer takeovers are harder to hide. Tooling adoption is uneven in 2026 — check whether your critical deps publish Sigstore signatures.

Share:XHacker NewsRedditLinkedIn

Related guides

Guide
Hallucinated package names in AI-generated code — detect, prevent, and recover

AI coding assistants invent plausible-sounding package names that don't exist — and attackers pre-register those hallucinated names on npm and PyPI with malware. This guide shows the attack, the verification workflow, and the production controls that defend against it.

Guide
Vibe coding security risks — the 2026 field guide

Vibe coding (AI-generated apps shipped with minimal human review) has a security problem. Here is a grounded look at what actually breaks, with dated public incidents, and the controls that work.

Guide
How to secure your MCP server — fingerprint pinning, scope locks, rug-pull defense

Model Context Protocol went 0 → 200,000+ servers in 9 months. The April 2026 Anthropic RCE flaw + the Invariant Labs tool-poisoning class disclosures forced every MCP-using team to harden their server hygiene. This guide walks the four attack classes (unknown-server smuggle, fingerprint drift, tool smuggle, scope escalation) and the operator-authored TOML catalog that closes them.

Guide
Detecting MCP server rug-pulls — when the tool catalog mutates after install

The rug-pull pattern: an MCP server ships a safe v1 catalog at install time, then mutates to a v2 catalog (with attacker-controlled tools) once it's running in your trust boundary. Invariant Labs disclosed this class in 2025; the Apr 2026 Anthropic RCE incident exploited a related design flaw. This guide ships the fingerprint-pinning + signature-verification defense.