Insecure Dependencies

Building your house with recalled materials — that's what happens when your npm packages have known vulnerabilities. Audit and update them.

What is this?

You are building a house and you buy lumber, wiring, and plumbing from various suppliers. Then you find out that some of those materials were recalled — the wiring is a fire hazard, the pipes contain lead. That is what insecure dependencies look like. Your website is built on dozens (sometimes hundreds) of npm packages, and some of them have known security vulnerabilities. Attackers know about these vulnerabilities too, and they actively scan the internet for sites using affected versions.

Why it matters

For your visitors: Vulnerable dependencies can be exploited to steal data, inject malicious code, or take over sessions. The infamous Log4Shell vulnerability (2021) affected millions of applications through a single logging library. Your visitors trust that your site is safe — vulnerable dependencies betray that trust without you or them realizing it.
For your business: Supply chain attacks are one of the fastest-growing attack vectors. When a vulnerability is published, automated scanners start looking for affected sites within hours. The longer you wait to update, the higher your risk. Data breach notification laws mean a compromise could cost you fines, legal fees, and reputation damage on top of the direct harm.
The standard: Run npm audit or bun audit regularly. Keep dependencies updated, especially security patches. Use tools like Dependabot, Renovate, or Snyk to automate vulnerability detection. Pin dependency versions in production to prevent unexpected changes.

Regular auditing and updates

# Check for known vulnerabilities
npm audit

# Auto-fix what can be fixed
npm audit fix

# Keep dependencies up to date
npx npm-check-updates -u
npm install

Install and forget

{
  "dependencies": {
    "lodash": "^4.17.15",
    "express": "^4.16.0",
    "moment": "^2.24.0"
  }
}
// Installed 3 years ago, never updated
// 12 known vulnerabilities, 3 critical

How to fix it

React / Next.js

Set up automated dependency auditing and keep your packages updated.

# Step 1: Check for vulnerabilities right now
npm audit
# or
bun audit 2>/dev/null || npx audit-ci

# Step 2: Auto-fix non-breaking updates
npm audit fix

# Step 3: Check for outdated packages
npx npm-check-updates

# Step 4: Update everything (test after!)
npx npm-check-updates -u
npm install
npm test

Add an audit check to your CI/CD pipeline:

# .github/workflows/security.yml
name: Security Audit
on:
  push:
    branches: [main]
  schedule:
    - cron: "0 9 * * 1" # Every Monday at 9am

jobs:
  audit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm ci
      - run: npm audit --audit-level=high

Enable Dependabot for automatic pull requests when vulnerabilities are found:

# .github/dependabot.yml
version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    open-pull-requests-limit: 10

Plain HTML

If you use any npm packages (via CDN or bundled), keep them updated.

<!-- BAD: old version with known vulnerabilities -->
<script src="https://cdn.jsdelivr.net/npm/jquery@3.3.1/dist/jquery.min.js"></script>

<!-- GOOD: latest patched version -->
<script src="https://cdn.jsdelivr.net/npm/jquery@3.7.1/dist/jquery.min.js"></script>

<!-- BETTER: use integrity hashes to prevent CDN tampering -->
<script
  src="https://cdn.jsdelivr.net/npm/jquery@3.7.1/dist/jquery.min.js"
  integrity="sha384-1H217gwSVyLSIfaLxHbE7dRb3v4mYCKbpQvzx0cegeju1MVsGrX5xXxAvs/HgeFs"
  crossorigin="anonymous"
></script>

Use Subresource Integrity (SRI) hashes on all CDN-loaded scripts. This ensures that even if a CDN is compromised, tampered files will not execute.

High impact — security~2 paws

Your app is only as secure as its weakest dependency. The cat checks what you are building with, not just what you built.

How the cat scores this

The scanner identifies JavaScript libraries loaded on the page (via CDN URLs, embedded version strings, and framework fingerprints) and cross-references them against known vulnerability databases. Libraries with critical or high-severity CVEs are flagged. The scanner also checks for very old library versions (more than 2 major versions behind) as a general risk indicator, even if no specific CVE is published. SRI hash attributes on external scripts earn positive credit.