Dependency audit

Skill Deadlymind/nanolama/skills/dependency-audit

A portable Claude Code skills library (plugin) for a Django 5.2 + Next.js 16 house stack: 30 model-agnostic, tenant-isolation-and-security-first skills.

Install

npx -y skills add Deadlymind/nanolama --skill dependency-audit

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

2 things to look at

21 days oldThe repository was created 21 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
1 stars1 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

Audits a project's Python and JavaScript dependencies for known CVEs and version drift — pip-audit for the backend, pnpm audit for the frontend, plus lockfile and pinning hygiene. Use when checking dependencies for vulnerabilities, adding or upgrading a package, reviewing a Dependabot or renovate PR, wiring a supply-chain gate into CI, or triaging an audit finding. Not for reviewing application code changes (see security-review) or general CI pipeline setup (see ci-cd).

SKILL.md

3.1 KB, as published. Nobody here has run it

Dependency audit (supply-chain hygiene)

When to use

Before adding or bumping a dependency, when a vulnerability scanner or bot flags one, and on a schedule in CI. A CVE in a transitive package is as real as a bug in your own code — treat the dependency tree as attack surface.

Pattern

Scan both ecosystems against advisory databases, from the committed lockfiles (so you audit exactly what ships), triage each finding (upgrade, or consciously accept with a recorded reason), and run the scan as a CI gate so new CVEs surface on their own.

Steps / idioms

Commit and audit from lockfiles — uv.lock/poetry.lock/pinned requirements.txt and pnpm-lock.yaml. Pin production deps; never audit a floating range.

Run both scanners; fail the build on the severity you care about:

# Python — pip-audit reads installed pkgs or a requirements file (OSV/PyPI advisories)
pip-audit -r requirements.txt --strict            # non-zero exit on any known CVE
#   pip-audit --fix                                # auto-bump where a safe version exists

# JavaScript — audit the pnpm workspace
pnpm audit --prod --audit-level=high              # non-zero exit at >= high
#   pnpm audit --fix                              # apply compatible upgrades

# Triage a finding you cannot fix yet: upgrade, or record an explicit, expiring waiver
#   (e.g. a pip-audit --ignore-vuln GHSA-xxxx with a comment + review date).

Automate the bumps: enable Dependabot or renovate, and review those PRs against this same checklist rather than merging blindly.
Vet new dependencies before adding: real project, active maintenance, sane transitive footprint, and the exact package name (guard against typosquats).

Adapt to your repo

Swap the tools for your package managers (npm audit/yarn npm audit, poetry, uv, osv-scanner, or safety as an alternative to pip-audit). Choose the --audit-level threshold your team enforces, and point the commands at your real lockfile paths.

Gotchas

Auditing installed packages instead of the lockfile hides what actually deploys — scan the lock.
--audit-level=high still lets moderate CVEs through; pick the threshold deliberately.
A "fix" that jumps a major version can break you — read the changelog, don't just take --fix.
Dev-only advisories still matter for your build/CI machines; scan dev deps too, separately.
Accepting a finding without an expiry turns into a permanent silent risk — set a review date.