dependency-audit

Dependency Audit

Overview

Every dependency is code you didn't write, can't fully control, and must trust. The average npm project has 200+ transitive dependencies. Each one is a potential vulnerability, a potential breaking change, and a potential abandoned project.

Core principle: Every dependency is a liability until proven otherwise. Justify every one.

The Iron Law

NO NEW DEPENDENCY WITHOUT JUSTIFICATION. NO UNAUDITED DEPENDENCY IN PRODUCTION. NO DEPENDENCY WITHOUT AN EXIT STRATEGY.

When to Use

• Adding a new dependency (always audit before adding)
• Running periodic dependency health checks (quarterly minimum)
• After security advisory notifications (CVE alerts)
• Investigating unexplained behavior (could be dependency bug)
• During any codebase audit
• Before major version upgrades
• When build/install times are growing

When NOT to Use

• Choosing between two technologies (that's a design decision, not an audit)
• Evaluating your own code quality (use code-review or architecture-audit)
• If the project has zero external dependencies (rare but possible)

Anti-Shortcut Rules

YOU CANNOT:
- Say "dependencies look fine" — run the actual audit command and read the output
- Say "no vulnerabilities" — run npm audit / pip audit / equivalent AND check the output
- Say "package is maintained" — check last publish date, open issues count, contributor count
- Say "we need this dependency" — verify what fraction of it you use (one function from 500KB?)
- Skip transitive dependencies — they're the largest attack surface
- Say "license is fine" — verify the specific license against your project's license requirements
- Trust download counts alone — popular packages can be compromised too
- Say "we'll update later" — document WHEN and add it to the backlog with a deadline

Common Rationalizations (Don't Accept These)

Rationalization	Reality
"Everyone uses this package"	Popularity ≠ security. Popular packages are bigger targets for supply chain attacks.
"It's only a dev dependency"	Dev dependencies execute during build. A compromised build dependency compromises your artifact.
"We only use one function from it"	Then implement that function yourself. Don't ship 500KB for one utility.
"It's been around forever"	"Around forever" often means "unmaintained." Check last commit date.
"The vulnerability doesn't affect us"	Prove it with evidence. Most "doesn't affect us" claims are wishful thinking.
"We'll update when we have time"	You won't have time until the CVE becomes an incident. Schedule it now.
"Pinning versions protects us"	Pinning prevents auto-updates but also prevents auto-patches. You must actively manage pinned versions.