Dependency Risk Audit

Dependency Risk Audit

Third-party packages are the most common source of supply-chain compromise and known-vulnerability exploitation; treat dependency selection as a security decision, not a convenience one. The costly failure this skill prevents is on both ends: shipping a reachable critical CVE because the audit output was noise nobody read, and burning a sprint patching findings in code paths that can never execute.

Operating procedure

Step 1: gather inputs

Collect (label guesses as guesses):

1. Ecosystem and manifest/lockfile (package.json + lockfile, requirements/poetry, Gemfile.lock, go.mod).
2. Deployment context: server-side, client-side, CLI-only, or build-time only - this decides reachability.
3. License posture: proprietary/commercial code, or open source (decides copyleft tolerance).
4. Whether this is a point decision (one new package) or a full audit (whole tree).

Step 2: run the native audit and triage for reachability

Run the ecosystem's native tool first: npm audit, pip-audit, bundle audit, govulncheck (which does reachability analysis natively - trust its "not called" verdicts). For each finding:

• Confirm exploitability in context - a CVE in a CLI-only code path of a server-side lib may not be reachable. A dev-only dependency (test runner, linter) is almost never exploitable in production, but IS in scope for install-time attacks.
• Check whether a fixed version exists and whether upgrading is a semver-compatible bump.
• Red line: any CVSS 7.0+ finding with no available fix is a blocking risk requiring a compensating control or replacement.
• Never dismiss a finding without a written reason attached to it. "Probably fine" is not a reason; "the vulnerable function is X, we never call X, verified by grep" is.

Step 3: check maintenance health

A dependency with no CVEs today can become a liability tomorrow. For any new or high-traffic dependency:

• Last release and commit activity: no release in 24+ months on an active ecosystem is a yellow flag (in slow-moving ecosystems, judge by open-issue responsiveness instead).
• Open security issues versus closed, and whether reports get responses.
• A documented security policy or disclosure contact.
• Single-maintainer packages without a succession plan carry concentration risk - flag them; for anything on a critical path, require a fork-and-maintain fallback plan or an alternative identified in the report.