Outdated Deps

Vulnerable and Outdated Components Analysis

Analyze project dependencies for known vulnerabilities (CVEs), abandoned packages, unpinned versions, typosquatting risks, and excessive transitive dependency chains. This skill heavily relies on external scanners for CVE detection and uses Claude analysis for configuration hygiene, supply chain risks, and contextual assessment.

Supported Flags

Read ../../shared/schemas/flags.md for full flag documentation. This skill supports all cross-cutting flags.

Key flags for this skill:

Framework Context

OWASP Top 10 2021 -- A06: Vulnerable and Outdated Components

Applications are vulnerable when they use components with known vulnerabilities, do not track component versions, do not scan for vulnerabilities regularly, do not fix or upgrade underlying platforms in a timely fashion, or do not test compatibility of updated libraries.

CWE Mappings:

• CWE-1035: Using Software with Known Vulnerabilities (OWASP Top 10 specific)
• CWE-1104: Use of Unmaintained Third-Party Components
• CWE-937: Using Components with Known Vulnerabilities

STRIDE Mapping: All categories -- the impact depends on the specific vulnerability in the component. A vulnerable serialization library maps to Tampering and Elevation of Privilege; a vulnerable TLS library maps to Information Disclosure.

Detection Patterns

Read references/detection-patterns.md before running analysis. It contains Grep regex patterns for manifest file issues, lockfile analysis, and supply chain risk indicators.

Workflow

Step 1 -- Determine Scope

1. Parse --scope flag (default: changed).
2. Resolve to a concrete file list.
3. Identify dependency manifests and lockfiles in scope:
   • Node.js: package.json, package-lock.json, yarn.lock, pnpm-lock.yaml
   • Python: requirements.txt, requirements*.txt, Pipfile, Pipfile.lock, pyproject.toml, poetry.lock, setup.py, setup.cfg
   • Go: go.mod, go.sum
   • Rust: Cargo.toml, Cargo.lock
   • Java: pom.xml, build.gradle, build.gradle.kts, gradle.lockfile
   • Ruby: Gemfile, Gemfile.lock
   • PHP: composer.json, composer.lock
   • .NET: *.csproj, packages.config, Directory.Packages.props
   • Container: Dockerfile, docker-compose*.yml
4. If --scope changed returns no manifest files, expand to --scope module:<auto> to find the nearest manifest.

Step 2 -- Check for Scanners

Detect available scanners in priority order:

This skill depends heavily on scanners. If no scanners are available, warn the user prominently and recommend installing at least one. Claude analysis alone cannot reliably detect known CVEs -- it can only check configuration hygiene and supply chain indicators.

Step 3 -- Run Available Scanners

For each detected scanner relevant to the project ecosystem, run against the scoped manifests:

• npm audit: npm audit --json (from package.json directory)
• pip-audit: pip-audit --format json (from requirements.txt or pyproject.toml directory)
• trivy: trivy fs --format json --scanners vuln <target>
• osv-scanner: osv-scanner --format json -r <target>
• cargo-audit: cargo audit --json (from Cargo.toml directory)

Normalize scanner output to the findings schema per ../../shared/schemas/scanners.md.

Important: Run scanners from the correct working directory. Dependency scanners require being in the project root or the directory containing the manifest file.

Step 4 -- Claude Analysis

Even when scanners are available, Claude adds value by analyzing patterns that scanners miss. Using Grep and Read, search for patterns from references/detection-patterns.md:

1. Unpinned versions: Check manifests for loose version constraints (^, ~, *, >= without upper bound).
2. Missing lockfiles: Verify that each manifest has a corresponding lockfile committed.
3. Abandoned packages: Cross-reference package names with known abandoned or deprecated packages when recognizable.
4. Typosquatting risks: Look for package names that are one edit distance from popular packages.
5. Excessive dependencies: Flag manifests with unusually large dependency counts that increase attack surface.
6. License compliance: Note packages with restrictive or unknown licenses if detectable.

Merge Claude findings with scanner findings, deduplicating by package name and version.

Step 5 -- Report Findings

Output findings using the schema from ../../shared/schemas/findings.md.

Use the DEP prefix for finding IDs (e.g., DEP-001, DEP-002).

Group findings by category:

1. Known CVEs (from scanners) -- highest priority
2. Unpinned versions -- configuration hygiene
3. Missing lockfiles -- supply chain risk
4. Abandoned packages -- maintenance risk
5. Typosquatting candidates -- supply chain attack risk
6. Excessive transitive dependencies -- attack surface

What to Look For

1. Known CVEs in direct dependencies -- Vulnerabilities with published CVE identifiers in packages the project directly depends on.
2. Known CVEs in transitive dependencies -- Vulnerabilities in packages pulled in indirectly through the dependency tree.
3. Unpinned dependency versions -- Version ranges that allow automatic updates to potentially vulnerable versions (^, ~, *, >=).
4. Missing lockfiles -- Manifests without committed lockfiles mean builds are not reproducible and dependency resolution can vary.
5. Abandoned or unmaintained packages -- Dependencies with no updates in 2+ years, archived repositories, or known deprecation notices.
6. Typosquatting candidates -- Package names suspiciously similar to popular packages (e.g., lodahs vs lodash, reqeusts vs requests).
7. Excessive transitive dependencies -- A single direct dependency pulling in hundreds of transitive packages increases supply chain attack surface.
8. Packages from untrusted registries -- Dependencies sourced from non-default registries, private URLs, or git repositories without integrity checks.
9. Outdated major versions -- Running multiple major versions behind, even without known CVEs, increases the risk window for future disclosures.

Scanner Integration

See ../../shared/schemas/scanners.md for full scanner invocation details. This skill primarily uses:

Scanner availability is critical for this skill. Without scanners, the skill can only detect configuration-level issues (unpinned versions, missing lockfiles) but cannot reliably identify known CVEs.

When scanners are unavailable:

1. Warn: "No dependency scanner available. CVE detection requires a scanner. Install one of: npm audit (built-in), pip-audit, trivy, osv-scanner."
2. Proceed with Claude-only analysis for configuration hygiene patterns.
3. Report findings with confidence: low for anything that would need scanner confirmation.

Output Format

All findings use the schema defined in ../../shared/schemas/findings.md.

ID Prefix: DEP (e.g., DEP-001)

References for each finding:

• references.owasp: A06:2021
• references.cwe: CWE-1035 (known vulns) or CWE-1104 (unmaintained)
• references.stride: Depends on the specific vulnerability
• metadata.tool: outdated-deps
• metadata.framework: owasp
• metadata.category: A06

For CVE findings, also include:

• references.cve: The CVE identifier (e.g., CVE-2023-44270)
• fix.summary: The fixed version or upgrade command

Summary table after all findings:

| Severity | Count |
|----------|-------|
| CRITICAL | N     |
| HIGH     | N     |
| MEDIUM   | N     |
| LOW      | N     |

| Category                  | Count |
|---------------------------|-------|
| Known CVEs                | N     |
| Unpinned Versions         | N     |
| Missing Lockfiles         | N     |
| Abandoned Packages        | N     |
| Typosquatting Candidates  | N     |
| Excessive Dependencies    | N     |

Followed by:

• Top 3 priorities (usually the highest-severity CVEs)
• Recommended upgrade commands
• Overall dependency health assessment paragraph