Dependency Review

Dependency audit covering vulnerability scanning, license compliance, and staleness. This skill only analyzes: it never touches code or lock files. It also never auto-installs upgrades or missing audit tools, reporting anything missing as unavailable instead.

Cite exact package names/versions/CVE IDs from actual tool output, never estimate or invent them.

Audit Workflow

Phase 1: Detect Package Managers & Technology Stack

Discover all package managers present in the project:

Use Glob to check for the existence of these files:
- package.json / package-lock.json / yarn.lock / pnpm-lock.yaml → npm/yarn/pnpm (Node.js)
- pyproject.toml / requirements*.txt / Pipfile / setup.py → pip/uv/poetry (Python)
- Cargo.toml / Cargo.lock → cargo (Rust)
- go.mod / go.sum → go modules (Go)
- composer.json / composer.lock → composer (PHP)
- Gemfile / Gemfile.lock → bundler (Ruby)
- *.csproj / packages.config / Directory.Packages.props → NuGet (.NET)
- pom.xml / build.gradle / build.gradle.kts → Maven/Gradle (Java/Kotlin)
Read each detected manifest to understand:
- Total number of direct dependencies
- Total number of dev dependencies
- Whether lock files are present and committed
- Workspace/monorepo structure (multiple package.json, Cargo.toml workspaces, etc.)

Phase 2: Run Native Audit Commands

Execute the audit command for each detected package manager. Run independent commands in parallel, and save all raw output (including "tool not installed" errors) for Phase 3. Commands per ecosystem are in references/audit-commands.md, load it now.

Phase 3: Analyze Vulnerabilities, Licenses, and Staleness

Analyze the Phase 2 output across three dimensions (vulnerability triage, license compliance, staleness/upgrade complexity) scoped per the Scoping section below. Detailed per-dimension steps and risk-classification tables are in references/agent-prompts.md, load it before starting this phase.

Default to doing all three passes yourself, sequentially, in the current context: this is classification over data already fetched in Phase 2, not independent research, so a 3-way agent fan-out mostly re-reads the same output three times. Only spawn parallel Explore agents (one per dimension) when the audit output is unusually large: a multi-ecosystem monorepo, or output that would blow the context budget for a single pass. If no subagent/task tool is available, always do the three passes inline sequentially: that is the correct behavior for most runs anyway, not a degraded fallback.

Whichever mode you use:

1. Read lock files for transitive dependency details when needed
2. Provide structured findings with evidence from actual tool output
3. Classify risk level (Critical/High/Medium/Low)
4. Recommend specific actions with exact target versions

Phase 4: Risk Assessment & Prioritization

1. Collect all findings across the three dimensions.
2. Deduplicate: remove findings reported under more than one dimension.
3. Cross-reference: combine vulnerability + license + staleness data per package.

4. Prioritize by composite risk, using this severity table:

   Severity	Criteria
   Critical	Known exploited CVEs (CISA KEV), RCE vulnerabilities, packages with no maintained fork
   High	High-severity CVEs with public exploits, copyleft license in a proprietary project, packages 3+ major versions behind
   Medium	Medium-severity CVEs without a public exploit, permissive-but-unusual licenses, packages 1-2 major versions behind
   Low	Low-severity CVEs, informational license notes, minor version drift

5. Group findings by action type: security patches (non-breaking), major upgrades (breaking), or replacements for abandoned packages.
6. Report statistics: total dependencies, vulnerable count, license-risky count, stale count.

Phase 5: Generate Dependency Report

Generate a comprehensive markdown report following the template in references/report-template.md.

Phase 6: Verification & Quality Check

Before presenting the report, verify:

1. Every vulnerability finding has a CVE/GHSA ID or audit tool reference
2. Every finding references the exact installed version and fix version
3. License findings reference the actual license field from the package manifest
4. Staleness findings include the current and latest versions plus the release date
5. Statistics are accurate (counted from actual tool output, not estimated)
6. No duplicate findings across categories
7. Risk ratings are justified with evidence
8. Upgrade recommendations include breaking change warnings where applicable
9. No invented CVEs or license types, and no made-up version numbers
10. Dependabot alerts are reconciled with local audit results

Scoping

By default, run all three dimensions (vulnerabilities, licenses, staleness) at medium severity and above. If the user asks to scope to just one dimension (e.g. "just check for vulnerabilities" or "license risk only"), run only that phase. If they ask to filter by severity (e.g. "critical only"), filter the report to that level and above.

Limitations

References

• OWASP Dependency-Check
• GitHub Advisory Database
• CISA Known Exploited Vulnerabilities
• SPDX License List
• OSI Approved Licenses
• OpenSSF Scorecard