agentsclimarketplace

Supply chain security

Skill ShieldNet-360/secure-vibe/dist/agent-skills/.agents/skills/supply-chain-security

SecureVibe — prevention-first security for AI-written code. Signed SKILL.md knowledge that makes AI coding assistants write secure code at generation time, plus a deterministic CI gate. Offline · keyless · Ed25519-signed. By ShieldNet360.

Install
npx -y skills add ShieldNet-360/secure-vibe --skill supply-chain-security

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 2 stars2 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Defend against typosquats, dependency confusion, and malicious package contributions — Applies to: when AI is asked to add a dependency; when reviewing PRs that modify package manifests; when setting up a new project that uses internal namespaces; before publishing a package to a public registry

SKILL.md

3.8 KB, as published. Nobody here has run it

<!-- Native skill bundle for agent-skills (cross-tool convention). Generated by `secure-vibe dev regenerate`. --> <!-- Do not edit by hand; the source of truth is skills/supply-chain-security/SKILL.md. -->

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.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.