Supply Chain Security

Supply Chain Security

Defend against typosquats, dependency confusion, and malicious package contributions

ALWAYS

• Compute Levenshtein distance against the top-1000 list for the relevant ecosystem whenever proposing a new dependency. Flag any candidate with distance ≤ 2 from a popular package (axois vs axios, urlib3 vs urllib3, colours vs colors, python-dateutil vs dateutil vs dateutils).
• Verify that internal-namespace packages (@yourco/*, com.yourco.*) are pulled from the internal registry, not the public one. Configure .npmrc / pip.conf / settings.gradle with the internal scope explicitly.
• Pin the registry URL in lockfiles to prevent registry redirection attacks.
• Check that any newly added package has a verified maintainer (npm provenance, sigstore signature, or GPG-signed git tag) when published in the last 90 days.
• Treat install scripts (postinstall, preinstall, setup.py arbitrary code, build.rs) as high-risk surface and flag them in the PR description for human review.
• Secure your application's own update / release channel, not just third-party deps. Require authentication and a release-manager role on the endpoint that publishes a release, and have the client verify a signature (or pinned checksum) over the downloaded artifact before executing it. The publish-then-clients-auto-download path is a supply chain too: poison one release and every client runs it.

NEVER

• Add a public package whose name matches an internal namespace pattern.
• Trust a package whose repository URL on the registry page does not match its actual source repo.
• Recommend a freshly-published package with low download counts for a security-critical use case (auth, crypto, HTTP, DB drivers).
• Disable the package manager's integrity check (--no-package-lock, --ignore-scripts = false when defending against it, npm config set audit false in production).
• Auto-merge dependency-bump PRs without a reviewer when the bump crosses a major version.
• Suggest installing tools via curl | sh patterns from untrusted sources.
• Let any authenticated user — or, worse, an unauthenticated request — publish or overwrite a release artifact that other users' clients auto-download, or have the client execute an update without verifying a signature / pinned checksum. Either one is a one-poison-many-RCE supply-chain break.

KNOWN FALSE POSITIVES

• Legitimate orgs forking and republishing maintained packages with a -fork or -community suffix; verify the fork's repo URL before flagging.
• Beta / alpha releases of well-known packages (e.g. next@canary) appear "newly published" but are part of a known release cadence.
• Internal namespace packages (@yourco/internal-tools) intentionally not on the public registry — these are fine when the .npmrc is configured correctly.
• Auto-update frameworks that verify a signature by default (Sparkle, electron-updater with a pinned public key, Omaha) are the correct pattern — flagging "the app auto-updates" is an FP; the control is signature / checksum verification, not the absence of auto-update.
• A staging / dev update feed without signing is acceptable when it's gated behind an env flag or internal network and never serves production clients.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: ShieldNet-360
• Source: ShieldNet-360/secure-vibe
• License: MIT

Install and usage instructions live in the source repository linked above.