Skip to the rows

agentsclimarketplace

Dependency audit

Skill ShieldNet-360/secure-vibe/dist/claude-skills/.claude/skills/dependency-audit

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 dependency-audit

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

Audit project dependencies for known vulnerabilities, malicious packages, and supply chain risks — Applies to: when adding a new dependency; when upgrading dependencies; when reviewing package manifests (package.json, requirements.txt, go.mod, Cargo.toml); before merging a PR that modifies dependency files

SKILL.md

3.2 KB, as published. Nobody here has run it

Dependency Audit

Audit project dependencies for known vulnerabilities, malicious packages, and supply chain risks

ALWAYS

Pin dependencies to exact versions in lockfiles (package-lock.json, yarn.lock, Pipfile.lock, poetry.lock, go.sum, Cargo.lock).
Cross-check every new dependency name against the bundled malicious-package list in vulnerabilities/supply-chain/malicious-packages/.
Prefer well-established packages with high download counts, multiple maintainers, and recent activity over newer alternatives that solve the same problem.
Run the package manager's audit command (npm audit, pip-audit, cargo audit, govulncheck) and review reported issues before merging.
Verify the package's repository URL on the package page actually exists and matches the linked GitHub / GitLab / Codeberg project.
Track embedded runtimes you ship — a bundled browser engine (Electron / CEF / Chromium / system WebView), a language runtime, or a JRE — against their upstream EOL and security releases. Their CVEs are filed against the upstream project, not the wrapper package (electron, pywebview, …), so npm audit / Trivy / Dependabot match the wrapper version and report the engine as clean. Pin a supported major; auto-update it.

NEVER

Add a dependency without pinning its version.
Install packages with --unsafe-perm or equivalent flags that bypass install sandboxing.
Add a dependency whose name appears in the bundled malicious-package list.
Add a brand-new package (published within the last 30 days) without a clear, documented reason — typosquats are usually freshly published.
Use the latest tag in a production lockfile or container image FROM line.
Commit unused dependencies — they expand the attack surface for free.
Ship an end-of-life embedded runtime (an Electron major past EOL, an unpatched bundled Chromium / CEF, an EOL JRE) and rely on dependency scanners to catch it — they don't map the engine's CVEs to the wrapper package, so known RCE CVEs reachable via rendered / parsed content pass as "clean".

KNOWN FALSE POSITIVES

Internal monorepo packages (@yourco/*) flagged as "unknown" — these are valid when the namespace is owned by your organization.
New patch versions of stable packages (e.g. [email protected] after 18.2.4) flagged as "recently published" — patch updates are usually fine.
Package names that legitimately overlap with malicious entries from years ago that have been re-registered by the original maintainer.
A wrapper package pinned to a currently-supported major whose bundled engine is patched is fine — the finding is an EOL/unpatched engine, not the presence of an embedded runtime.

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.