Dependency Audit
Trigger phrases: "dependency audit", "npm audit", "package security", "CVE", "license", "deprecated package", "still maintained", "no longer maintained", "unmaintained", "third party library", "supply chain"
This skill only reports. It changes no manifest and no lockfile — bringing dependencies current is
[[dependency-upgrade]], which classifies each move by risk and verifies the build. Keeping the two apart keeps
this one safe to run any time, on any branch, including one you are only inspecting.
Audit axes
- Known vulnerabilities (CVE): audit appropriate to the ecosystem
npm audit --production # Node
dotnet list package --vulnerable # .NET (cannot be combined with --deprecated/--outdated)
pip-audit # Python
- License compliance: flag licenses incompatible with the project such as copyleft/GPL (a risk in commercial closed source).
- Maintenance status: abandoned / long-unmaintained / single-maintainer packages, and packages the registry
itself marks deprecated —
dotnet list package --deprecated, npm view <pkg> deprecated. A deprecated
package is not a version problem: no bump fixes it, it needs a replacement.
- Transitive dependencies: also scan vulnerabilities in indirect dependencies.
- Lockfile integrity: lockfile committed and consistent with the manifest; versions pinned.
- Justification for new dependencies: is it actually needed? Don't add a heavy package for a single small function (supply-chain surface).
- Install-time execution: does any dependency run code during installation —
preinstall/install/
postinstall scripts — and prepare, which runs only for a git, link or folder dependency and never for a
registry tarball — a build hook, or a setup step that fetches at install time? This is the mechanism the recent
registry compromises actually used: the malicious version does not have to be imported, only installed, so a
CVE feed and a code review both miss it. Ask two things: which packages declare such a script, and whether
the project can install without them at all (npm ci --ignore-scripts; for Python the control is refusing source
distributions, pip install --only-binary=:all:, optionally with --require-hashes — a wheel has no install
hook, an sdist does; or a vendored, pre-built artefact). A package that cannot install without running code is not disqualified —
it is a package whose publisher you are trusting with arbitrary execution on every machine and every runner,
which is a decision, not a default.
- Publisher concentration — read it from the registry, not from the repository. "Many contributors" on a
forge says who can open a pull request; it does not say who can publish. The number that matters is who holds
the publish right on the registry (
npm owner ls <pkg> · for PyPI the package JSON's ownership.roles,
NOT the self-reported info.maintainer field · the equivalent ACL for the ecosystem in use) — and whether the
PUBLISH PATH itself is challenged, which is not the same as "the account has 2FA": npm's auth-only 2FA mode
does not gate npm publish, and a granular token with bypass-2FA publishes with no second factor, while on
PyPI 2FA has been mandatory for every account since 2024 so the real question there is Trusted Publisher
versus a long-lived API token. A widely-used
package whose registry ACL is one unprotected account is a single compromised credential away from every
build that installs it, whatever the contributor graph looks like.
Output
Severity-sorted list: package · version · issue (CVE/license/maintenance) · upgrade path.
DoD
- 0 known HIGH/CRITICAL vulnerabilities; licenses compliant; lockfile consistent; every new package justified.
- Every axis resolves to one of three states, and the third is a real answer: assessed-clean,
assessed-flagged, or not assessable here — and why. An axis that was skipped because the tool is missing,
the registry was unreachable, or the ecosystem has no equivalent is reported as unassessed, never folded into
the clean count. A report that cannot tell "nothing found" from "nobody looked" is the failure this skill
exists to prevent, and the sibling
security-scan already holds the same rule.
1---2name: dependency-audit3description: Dependency risk assessment, read-only: known CVEs, deprecated packages, licence compliance, maintenance status, lockfile integrity, and a justification for every new dependency. Acting on it is dependency-upgrade.4---56# Dependency Audit78<!-- routing-eval reads this line; it lives in the BODY so the always-on skill LISTING stays inside9 Claude Code's budget (1% of the context window) — an overflowing listing gets descriptions10 truncated or dropped, which strips the very keywords a match depends on. -->11Trigger phrases: "dependency audit", "npm audit", "package security", "CVE", "license", "deprecated package", "still maintained", "no longer maintained", "unmaintained", "third party library", "supply chain"1213**This skill only reports.** It changes no manifest and no lockfile — bringing dependencies current is14[[dependency-upgrade]], which classifies each move by risk and verifies the build. Keeping the two apart keeps15this one safe to run any time, on any branch, including one you are only inspecting.1617## Audit axes181. **Known vulnerabilities (CVE):** audit appropriate to the ecosystem19 ```bash20 npm audit --production # Node21 dotnet list package --vulnerable # .NET (cannot be combined with --deprecated/--outdated)22 pip-audit # Python23 ```242. **License compliance:** flag licenses incompatible with the project such as copyleft/GPL (a risk in commercial closed source).253. **Maintenance status:** abandoned / long-unmaintained / single-maintainer packages, and packages the registry26 itself marks **deprecated** — `dotnet list package --deprecated`, `npm view <pkg> deprecated`. A deprecated27 package is not a version problem: no bump fixes it, it needs a replacement.284. **Transitive dependencies:** also scan vulnerabilities in indirect dependencies.295. **Lockfile integrity:** lockfile committed and consistent with the manifest; versions pinned.306. **Justification for new dependencies:** is it actually needed? Don't add a heavy package for a single small function (supply-chain surface).317. **Install-time execution:** does any dependency run code during installation — `preinstall`/`install`/32 `postinstall` scripts — and `prepare`, which runs only for a git, link or folder dependency and never for a33 registry tarball — a build hook, or a setup step that fetches at install time? This is the mechanism the recent34 registry compromises actually used: the malicious version does not have to be imported, only installed, so a35 CVE feed and a code review both miss it. Ask two things: which packages declare such a script, and whether36 the project can install without them at all (`npm ci --ignore-scripts`; for Python the control is refusing source37 distributions, `pip install --only-binary=:all:`, optionally with `--require-hashes` — a wheel has no install38 hook, an sdist does; or a vendored, pre-built artefact). A package that cannot install without running code is not disqualified —39 it is a package whose publisher you are trusting with arbitrary execution on every machine and every runner,40 which is a decision, not a default.418. **Publisher concentration — read it from the registry, not from the repository.** "Many contributors" on a42 forge says who can open a pull request; it does not say who can publish. The number that matters is who holds43 the publish right on the registry (`npm owner ls <pkg>` · for PyPI the package JSON's `ownership.roles`,44 NOT the self-reported `info.maintainer` field · the equivalent ACL for the ecosystem in use) — and whether the45 PUBLISH PATH itself is challenged, which is not the same as "the account has 2FA": npm's `auth-only` 2FA mode46 does not gate `npm publish`, and a granular token with bypass-2FA publishes with no second factor, while on47 PyPI 2FA has been mandatory for every account since 2024 so the real question there is Trusted Publisher48 versus a long-lived API token. A widely-used49 package whose registry ACL is one unprotected account is a single compromised credential away from every50 build that installs it, whatever the contributor graph looks like.5152## Output53Severity-sorted list: `package · version · issue (CVE/license/maintenance) · upgrade path`.5455## DoD56- 0 known HIGH/CRITICAL vulnerabilities; licenses compliant; lockfile consistent; every new package justified.57- **Every axis resolves to one of three states, and the third is a real answer:** *assessed-clean*,58 *assessed-flagged*, or *not assessable here — and why*. An axis that was skipped because the tool is missing,59 the registry was unreachable, or the ecosystem has no equivalent is reported as unassessed, never folded into60 the clean count. A report that cannot tell "nothing found" from "nobody looked" is the failure this skill61 exists to prevent, and the sibling `security-scan` already holds the same rule.