Dependency Vulnerability Audit

Dependency Vulnerability Audit

Overview

This skill coordinates supply chain security assessment across three dimensions: vulnerability scanning (via real CLI tools), license compliance, and supply chain risk. It delegates CVE detection to actual vulnerability scanners that use live databases — LLM knowledge has a cutoff and cannot reliably detect recent CVEs.

Scanner-to-Ecosystem Mapping

Important: Non-zero exit codes from vulnerability scanners indicate findings, not errors. Treat scanner exit code != 0 as "vulnerabilities found," not "command failed."

The INCOMPLETE Verdict

When no scanner is available for the detected ecosystem, the verdict MUST be INCOMPLETE — not PASS. INCOMPLETE honestly represents that the vulnerability check could not be performed. License and supply chain analysis can still run, but CVE data will be missing.

CVE Vulnerability Scanning

Severity Categorization

• Critical: RCE, authentication bypass, data exfiltration — must fix before shipping
• High: Significant security impact — should fix soon
• Medium: Limited impact or requires unusual conditions — review and plan fix
• Low: Minimal impact — track but lower priority

For Each Finding, Identify

• Package name and affected version
• CVE/vulnerability ID (e.g., CVE-2024-XXXXX, GHSA-XXXXX)
• Severity (use scanner-reported severity)
• Whether a fixed version is available
• Whether the vulnerable package is a direct dependency or transitive

License Compliance

LLM analysis is appropriate for license review since license data is stable (licenses don't change after release) and terms are documented.

License Risk Categories

What to Flag

• GPL-incompatible license combinations
• Dependencies with unknown licenses (mark for manual verification)
• License changes between versions

Supply Chain Risk Assessment

Heuristic analysis — findings require human verification against package registries.

Typosquatting Indicators

• Package names very similar to popular packages (e.g., lodash vs l0dash)
• Unusual character substitutions
• Suspicious name patterns for the ecosystem

Maintenance Health

• Packages known to be unmaintained or deprecated
• Packages with recent ownership transfers
• Packages with known malicious versions in their history

Dependency Sprawl

• Unusually large dependency count for the project type
• Dependencies duplicating functionality of other dependencies
• Dependencies for trivial functionality (single-function packages)

Version Pinning

• Dependencies using exact versions (good) vs. wide ranges (risk)
• Lock file present (good) vs. absent (risk)
• Any dependency using * or latest as version (high risk)

Verdict Rules

In priority order:

1. BLOCKED — Any Critical severity CVE found. Mandatory remediation before shipping.
2. INCOMPLETE — No scanner was available. CVE vulnerability data is missing. Cannot report PASS.
3. PASS_WITH_NOTES — No Critical CVEs, but any of: High severity CVEs, license compliance flags, supply chain concerns.
4. PASS — Scanner ran successfully, no CVEs found, no license flags, no supply chain concerns.

Report Structure

markdownCopy code
# Dependency Audit Report

**Ecosystem:** [ecosystem]
**Manifest:** [manifest path]
**Scanner used:** [scanner name or 'none — INCOMPLETE']

## Executive Summary
[2-3 sentences on overall security posture]

**Verdict:** [PASS / PASS_WITH_NOTES / BLOCKED / INCOMPLETE]

## Vulnerability Findings
[CVE table by severity: Package | CVE ID | Description | Fixed Version | Direct/Transitive]

## License Compliance
[Flagged dependencies table: Package | License | Concern | Recommendation]

## Supply Chain Risk
[Typosquatting suspects, maintenance concerns, version pinning summary]

## Remediation Priorities

### Immediate (Critical/High vulnerabilities)
[Numbered list with package, CVE, fix command]

### Short-term (Medium vulnerabilities, license concerns)
[Numbered list]

### Monitor (Low vulnerabilities, supply chain flags)
[Numbered list]