engineeringsecurity
Dependency Audit
Audit project dependencies for security vulnerabilities, license compliance, outdated versions, and supply-chain risks. Produces a prioritized triage report with update recommendations and risk mitigation steps.
dependenciessecurityvulnerabilitieslicensesupply-chainnpmaudit
Works well with agents
Works well with skills
$ npx skills add The-AI-Directory-Company/(…) --skill dependency-auditSKILL.md
Markdown
| 1 | |
| 2 | # Dependency Audit |
| 3 | |
| 4 | ## Before you start |
| 5 | |
| 6 | Gather the following from the user. If anything is missing, ask before proceeding: |
| 7 | |
| 8 | 1. **What is the project?** — Repository path or URL |
| 9 | 2. **What package manager?** — npm, yarn, pnpm, pip, cargo, go modules, maven, etc. |
| 10 | 3. **What environment?** — Production app, internal tool, library published to a registry |
| 11 | 4. **What is the license policy?** — Allowed licenses (e.g., MIT, Apache-2.0) and banned licenses (e.g., GPL-3.0 for proprietary projects) |
| 12 | 5. **What is the risk tolerance?** — Zero critical vulns allowed, or acceptable thresholds per severity |
| 13 | 6. **Is there a lockfile?** — Presence and freshness of `package-lock.json`, `yarn.lock`, `Cargo.lock`, etc. |
| 14 | |
| 15 | ## Audit procedure |
| 16 | |
| 17 | ### 1. Inventory Dependencies |
| 18 | |
| 19 | Generate a complete dependency list with versions: |
| 20 | |
| 21 | - **Direct dependencies**: Listed in the manifest file (package.json, requirements.txt, Cargo.toml) |
| 22 | - **Transitive dependencies**: Resolved from the lockfile — these are the majority of your attack surface |
| 23 | - **Dev-only dependencies**: Separate from production deps — lower risk but still relevant for CI supply-chain attacks |
| 24 | |
| 25 | Record total counts: direct, transitive, dev-only. Flag projects with more than 500 transitive dependencies as high-complexity. |
| 26 | |
| 27 | ### 2. Security Vulnerability Scan |
| 28 | |
| 29 | Run the ecosystem's built-in audit tool: |
| 30 | |
| 31 | - npm/yarn/pnpm: `npm audit`, `yarn audit`, `pnpm audit` |
| 32 | - pip: `pip-audit` or `safety check` |
| 33 | - cargo: `cargo audit` |
| 34 | - go: `govulncheck ./...` |
| 35 | |
| 36 | For each vulnerability found, record: package name, installed version, severity (critical/high/medium/low), CVE ID, fixed version, and whether the vulnerable code path is reachable. |
| 37 | |
| 38 | ### 3. License Compliance Check |
| 39 | |
| 40 | Extract the license for every dependency (direct and transitive): |
| 41 | |
| 42 | - Use `license-checker` (npm), `pip-licenses` (Python), `cargo-license` (Rust), or equivalent |
| 43 | - Flag any dependency with: no declared license, a copyleft license in a proprietary project, a license not on the approved list |
| 44 | - Check for license conflicts — e.g., combining LGPL and Apache-2.0 has specific requirements |
| 45 | |
| 46 | Produce a license summary table: license type, count of packages, compliance status. |
| 47 | |
| 48 | ### 4. Outdated Version Analysis |
| 49 | |
| 50 | Check how far behind each dependency is from its latest version: |
| 51 | |
| 52 | - Run `npm outdated`, `pip list --outdated`, `cargo outdated`, or equivalent |
| 53 | - Classify each outdated package: patch behind (low risk), minor behind (medium), major behind (high, likely breaking changes) |
| 54 | - Flag dependencies that are unmaintained: no release in 12+ months, archived repository, or no response to open security issues |
| 55 | |
| 56 | ### 5. Supply-Chain Risk Assessment |
| 57 | |
| 58 | Evaluate supply-chain risks for direct dependencies: |
| 59 | |
| 60 | - **Maintainer count**: Single-maintainer packages are higher risk for abandonment or account compromise |
| 61 | - **Download/usage trends**: Sudden drops may indicate a fork or deprecation |
| 62 | - **Typosquatting**: Verify package names match the intended library — check for similar-named malicious packages |
| 63 | - **Install scripts**: Flag packages with `preinstall`/`postinstall` scripts that execute arbitrary code |
| 64 | - **Dependency depth**: Flag packages that pull in 50+ transitive dependencies for a simple task |
| 65 | |
| 66 | ### 6. Prioritized Triage Report |
| 67 | |
| 68 | Rank all findings by severity and actionability: |
| 69 | |
| 70 | | Priority | Finding | Category | Action | Effort | |
| 71 | |----------|---------|----------|--------|--------| |
| 72 | | P0 | lodash 4.17.15 — prototype pollution (CVE-2021-23337) | Security | Update to 4.17.21 | Low | |
| 73 | | P1 | colors 1.4.0 — maintainer sabotage incident | Supply-chain | Pin to 1.3.0 or replace | Medium | |
| 74 | | P2 | GPL-3.0 dep in proprietary project | License | Replace with MIT alternative | High | |
| 75 | | P3 | express 4.x — major version 5.x available | Outdated | Evaluate migration | High | |
| 76 | |
| 77 | - **P0**: Critical/high security vulns with a fix available — update immediately |
| 78 | - **P1**: Supply-chain risks or license violations — address this sprint |
| 79 | - **P2**: High-severity outdated deps or medium vulns — schedule within the quarter |
| 80 | - **P3**: Minor version lag or low-severity findings — backlog |
| 81 | |
| 82 | ### 7. Remediation Steps |
| 83 | |
| 84 | For each P0/P1 finding, provide specific remediation: |
| 85 | |
| 86 | - Exact command to update (e.g., `npm install lodash@4.17.21`) |
| 87 | - Whether the update requires code changes (breaking API differences) |
| 88 | - If no fix exists: workaround, alternative package, or version pinning strategy |
| 89 | - For license issues: list 2-3 alternative packages with compatible licenses |
| 90 | |
| 91 | ## Quality checklist |
| 92 | |
| 93 | Before delivering the audit report, verify: |
| 94 | |
| 95 | - [ ] All direct and transitive dependencies are inventoried with version numbers |
| 96 | - [ ] Vulnerability scan ran against the lockfile, not just the manifest |
| 97 | - [ ] Every vulnerability includes CVE ID, severity, and fix version |
| 98 | - [ ] License compliance checked against the project's stated policy |
| 99 | - [ ] Outdated packages classified by how far behind they are |
| 100 | - [ ] Supply-chain risks assessed for at least all direct dependencies |
| 101 | - [ ] Findings are prioritized by severity and effort, not listed in discovery order |
| 102 | - [ ] P0/P1 items include specific remediation commands |
| 103 | |
| 104 | ## Common mistakes |
| 105 | |
| 106 | - **Auditing the manifest without a lockfile.** The manifest says `^4.0.0` but the lockfile resolves to `4.0.1` which has a known vuln. Always audit the lockfile. |
| 107 | - **Ignoring transitive dependencies.** Most vulnerabilities are in transitive deps you never explicitly chose. The audit must cover the full dependency tree. |
| 108 | - **Treating all vulnerabilities equally.** A critical RCE in a production dependency is not the same as a low-severity ReDoS in a dev-only test helper. Triage by reachability and environment. |
| 109 | - **Skipping license checks.** A GPL-3.0 transitive dependency in a proprietary SaaS can create legal exposure. License compliance is not optional. |
| 110 | - **Updating everything at once.** Batch updates hide which change broke something. Update P0 items individually, run tests after each, then batch lower-priority updates. |
| 111 | - **Ignoring unmaintained packages.** A dependency with no commits in two years will not get security patches. Plan a replacement before the vulnerability arrives. |
| 112 |