awesome-dependency-auditlisted

Read-only audit of a project's third-party dependencies — lockfile discipline, hallucinated and typosquatted package names (slopsquatting), dependency confusion, install-script exposure, maintenance and provenance, license conflicts, and CVE reachability — producing evidence-backed findings and a SHIP / FIX / BLOCK verdict. Use when the user asks to 'audit dependencies', 'check the supply chain', 'is this package safe', 'проверь зависимости', to review a package.json/requirements/go.mod change, before adding a dependency, or after a bot PR bumps versions. Do not use for vulnerabilities in the project's own source code (use awesome-security-audit), for CI workflow hardening (its CI/CD category covers that), or to execute the upgrades the audit calls for — use awesome-dependency-upgrade; this skill audits the dependency graph itself.
khasky/awesome-agent-skills · ★ 4 · AI & Automation · score 78

Install: claude install-skill khasky/awesome-agent-skills

# Dependency Audit Audit the third-party dependency graph — manifests, lockfiles, and the packages they resolve to — for supply-chain risk, before it ships with the product. Read-only: it reports findings and a verdict; it does not upgrade, pin, or remove anything. Hand the report to **awesome-dependency-upgrade** to act on. Two phases: **passive** (reading manifests, lockfiles, license files, changelogs already on disk — no gate) and **active** (anything that reaches a registry or scanner: `npm audit`, `pip-audit`, `osv-scanner`, registry metadata lookups — propose the commands and wait for approval first). Default to passive; say what staying passive leaves unverified. ## Scope and method 1. **Establish scope** — the whole graph, one manifest, or one diff (a bot bump, a new package). Name the ecosystems found (`package.json`, `requirements.txt`/`pyproject.toml`, `go.mod`, `Cargo.toml`, `pom.xml`/`gradle`, `Gemfile`). Include the repo's **agent extensions** in the graph when present — `.claude/`, `.agents/`, `.cursor/`, `.gemini/` skill and plugin folders, `.mcp.json` and equivalent MCP server lists, plugin-marketplace references, and any agent hook manifest. They install and execute on a contributor's machine exactly like a dependency, and no scanner covers them (Track C). 2. **Gather evidence** — manifests + lockfiles + install configuration (`.npmrc`, `pip.conf`, registry settings) + CI install commands. Every finding cites a file, a line, a version, or a scanner line