No packages with fewer than 50 weekly downloads

A production dependency with under 50 weekly downloads has almost no community scrutiny — no one is filing issues, no one is reviewing commits, and no one is running automated CVE scans against it. This makes it an ideal target for a supply chain takeover: an attacker can register a nearly identical package name or, if the package is already published, request maintainer access from an unresponsive original author. OWASP A06 covers the risk of components without active community oversight. CWE-1357 applies when the trustworthiness of a component cannot be independently verified. Low download counts also serve as a signal for typosquatting — the intended package likely has orders of magnitude more downloads than the misspelled one you may have accidentally installed.

For each low-download production dependency, run a quick provenance check:

npm info package-name

Compare the author, publish history, and download count against the package you intended to use. If the package is a genuine niche utility with no better alternative, consider vendoring it into src/lib/ to eliminate the external dependency entirely:

# Copy the source, remove the registry dependency
npm uninstall low-download-package
# paste the source into src/lib/package-name.ts

• ID: dependency-supply-chain.maintenance.min-download-threshold

• Severity: medium

• What to look for: Examine production dependencies in package.json. For each direct dependency, assess its ecosystem footprint. Well-known packages (any package you recognize as a standard library) pass automatically. For unfamiliar packages, check weekly download counts on the npm registry (https://www.npmjs.com/package/package-name). Focus on packages that appear custom, niche, or unfamiliar — not on minor utility packages you recognize. A package with fewer than 50 weekly downloads that is a production dependency is an unusual signal worth noting. Count all instances found and enumerate each.

• Pass criteria: All production dependencies are either recognizable well-known packages or have more than 50 weekly downloads as measured on npm. Threshold: at least 500 weekly downloads for every direct dependency.

• Fail criteria: A production dependency is unfamiliar AND has fewer than 50 weekly downloads.

• Skip (N/A) when: No package.json detected. Skip individual checks for packages where download count cannot be determined without network access.

• Detail on fail: "Package 'obscure-lib@0.1.0' in dependencies has very low download counts — verify this is the correct package and evaluate whether it is actively used by the community"

• Remediation: Low-download packages represent higher supply chain risk — they are less scrutinized by the community, more likely to be abandoned, and less likely to receive prompt security patches. They may also indicate that a typosquatting package was accidentally installed.

  Consider whether the package is:

  1. A better-known alternative spelled differently (typosquatting)
  2. A package you meant to scope differently
  3. A genuinely niche utility that has no better alternative

  If the package is genuinely needed and low-download, consider vendoring it (copying the source into your project) to eliminate the supply chain dependency.

  # Check download stats for all production dependencies
  for pkg in $(node -e "const p=require('./package.json'); console.log(Object.keys(p.dependencies||{}).join(' '))"); do
    echo "$pkg: $(npm view $pkg downloads --json 2>/dev/null | head -1)"
  done