Dependency audit

Skill jpoindexter/security-skills/dependency-audit

Agent skills for running security scans — secret scanning (gitleaks), dependency CVE audit (npm/cargo/osv), SAST (semgrep), and a composed pre-release gate. Grounded SKILL.md runbooks for Vanta / Claude Code / any skill-aware agent. MIT.

Install

npx -y skills add jpoindexter/security-skills --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

0 stars0 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

Scan dependencies for known CVEs across ecosystems — npm audit, cargo audit, osv-scanner (multi-ecosystem, catches what npm audit misses), pip-audit. Triage by reachability (runtime vs dev) and severity before mass-bumping.

SKILL.md

3.3 KB, as published. Nobody here has run it

Dependency Audit

Most of your attack surface is code you didn't write. This scan finds dependencies with known CVEs (the published ones — a database lookup, not analysis). The trap is reacting to the severity number alone: a 9.8 in a dev-only test runner is not a 9.8 in your shipped runtime. Triage by reachability first, severity second.

When to run

Before a release (a tagged version is what gets audited).
On a schedule (new CVEs land against deps you already shipped — yesterday's clean is today's stale).
After adding or bumping any dependency.

Run it — one ecosystem at a time, then the cross-cutting scanner

# Node / TS — runtime only first (what you actually ship), then everything.
npm audit --omit=dev          # the deps that ship in `npm install --omit=dev`
npm audit                     # + dev/build tooling

# Rust
cargo audit                   # reads Cargo.lock against the RustSec advisory DB

# Python
pip-audit                     # or: pip-audit -r requirements.txt

# Multi-ecosystem, recursive — the thorough net. Catches lockfiles the per-tool
# audits miss (sub-projects, docs sites) and flags dev deps explicitly.
osv-scanner scan source --recursive .

osv-scanner is the most complete — it walks every lockfile in the tree (including a docs site or sub-package the per-ecosystem tools never see) and labels (dev) so you can triage by reachability.

Triage — reachability BEFORE severity

For each finding, ask in order:

Does it ship? A (dev) dep (esbuild, vite, vitest, a linter) is NOT in your runtime if you install with --omit=dev. Real, but low urgency — it can't be hit by a user of the shipped artifact. Note it; don't panic-bump.
Is the vulnerable path reachable? A CVE in a code path you never call is lower priority than a medium in your hot path.
THEN severity. Among reachable, shipped deps, fix highest CVSS first.

Remediate — least-disruptive first

Patch bump (npm audit fix, cargo update -p <crate>) — safe, same major version. Do this freely.
Major bump (vite 5→6, vitest 2→3) — a breaking change. Do it deliberately in its own branch with the full test suite green after, NEVER as a blind audit fix --force before a release.
Override / pin a transitive dep to a patched version (overrides in package.json, [patch] in Cargo) when the direct dep hasn't updated yet.
Accept with a note when there's no fix and the dep is dev-only/unreachable — record WHY in a SECURITY.md or an allowlist so the next audit doesn't re-litigate it. Silent acceptance reads as "missed it."

The boundary

This finds known, published CVEs only — a zero-day or an unreported backdoor won't show. It's necessity, not sufficiency. Pair with [[sast-scan]] (your own code) and [[secret-scan]] (leaked credentials). Log what you deferred and why — see [[security-preflight]].