Dependency Auditor

License compliance for a Series B due diligence is a specific, high-stakes scan. Your lawyers need to confirm you have no copyleft contamination in your commercial product. Here's what the audit produces and what to watch for.

License Risk Tiers

Before showing inventory, understand the risk model:

The AGPL is the one that catches SaaS companies off guard. Standard GPL is triggered by distribution — SaaS technically doesn't distribute. AGPL closes that loophole: if users interact with AGPL software over a network, you must publish your source. That's your entire product.

License Inventory (Example Output)

npm (Node.js)

Package                    Version   License       Risk
─────────────────────────────────────────────────────────
express                    4.18.2    MIT           ✓ Safe
react                      18.3.1    MIT           ✓ Safe
lodash                     4.17.21   MIT           ✓ Safe
pg                         8.11.3    MIT           ✓ Safe
winston                    3.11.0    MIT           ✓ Safe
uuid                       9.0.0     MIT           ✓ Safe
@elastic/elasticsearch     8.12.0    Apache-2.0    ✓ Safe
bcryptjs                   2.4.3     MIT           ✓ Safe
helmet                     7.1.0     MIT           ✓ Safe
node-cron                  3.0.3     ISC           ✓ Safe

⚠ FLAGGED:
nodemailer                 6.9.9     MIT           ✓ Safe
chartjs-node-canvas        4.1.9     MIT           ✓ Safe
pdf-lib                    1.17.1    MIT           ✓ Safe

TOTAL: 47 direct deps — 44 MIT/Apache/ISC, 3 need manual review

Python (pip)

Package           License         Risk
────────────────────────────────────────
requests          Apache-2.0      ✓ Safe
pandas            BSD-3           ✓ Safe
numpy             BSD-3           ✓ Safe
sqlalchemy        MIT             ✓ Safe
celery            BSD-3           ✓ Safe
⚠ paramiko        LGPL-2.1        Review — safe if not modifying source
⚠ cryptography    Apache-2.0 +    ✓ Safe (dual-licensed)
                  BSD-3-Clause

Go modules

Module                          License      Risk
────────────────────────────────────────────────
github.com/gin-gonic/gin        MIT          ✓ Safe
github.com/go-redis/redis       BSD-2        ✓ Safe
github.com/spf13/cobra          Apache-2.0   ✓ Safe
github.com/gorilla/mux          BSD-3        ✓ Safe

Problematic Licenses — Action Required

If your audit surfaces any of these, here's what to do:

AGPL-3.0 dependency found:

1. Confirm the package is actually linked into your production binary (not just dev tooling)
2. If yes: find a permissively-licensed alternative or commercial equivalent
3. Common AGPL traps: some MongoDB drivers (use official mongodb npm package instead), some charting libs, some PDF generators

GPL-2.0 / GPL-3.0 found:

1. In npm: verify if the engines field shows it's a CLI tool only — GPL CLI tools used during build are generally not contaminating
2. In runtime deps: replace with MIT/Apache equivalent or obtain a commercial license from the vendor

SSPL (e.g., older MongoDB, Elastic):

• MongoDB switched to SSPL in 4.x; the official Node.js driver itself remains Apache-2.0
• If you're running self-hosted MongoDB 4+, the database binary is SSPL, not your code — this is acceptable
• If you're embedding SSPL code in your product, that's a problem

Tools Used

# npm — generate full license report
npx license-checker --production --csv > npm-licenses.csv
npx license-checker --production --failOn "GPL;AGPL;SSPL"

# Python
pip install pip-licenses
pip-licenses --format=csv > python-licenses.csv
pip-licenses --fail-on="GNU General Public License"

# Go
go install github.com/google/go-licenses@latest
go-licenses check ./... --disallowed_types=restricted,forbidden
go-licenses save ./... --save_path=./third_party_licenses

What to Give Your Lawyers

Deliver a single spreadsheet with columns: Package Name, Version, License, Ecosystem, Risk Tier, and Notes. Mark anything LGPL or above with a plain-English explanation of why it is or isn't a problem. Lawyers are not package managers — concrete yes/no language works better than technical nuance.

Most Node.js stacks are 95%+ MIT/ISC and pass cleanly. The risk is almost always in one obscure transitive dependency or a dev tool that someone accidentally pulled into the production bundle.

23 outdated dependencies spanning multiple major versions is a normal state for a project that's been moving fast. The mistake most teams make is trying to upgrade everything at once, or going purely by "most outdated" — neither is right. Here's a structured approach.

Prioritization Matrix

Score each dependency on two axes, then sequence accordingly:

Priority = Security risk × Usage criticality — breaking change risk informs sequencing, not whether to upgrade.

A major version jump on eslint (build tool) is low risk. A major version jump on jsonwebtoken (auth) needs a full test run even for a minor change.

Understanding Semver Risk

Given a version number MAJOR.MINOR.PATCH:

PATCH (1.2.3 → 1.2.4)  — Bug fix, no API change. Upgrade freely.
MINOR (1.2.3 → 1.3.0)  — New features, backwards compatible. Generally safe.
MAJOR (1.2.3 → 2.0.0)  — Breaking changes. Read the migration guide.

Packages 3+ major versions behind (e.g., webpack@3 when webpack@5 is current) often have accumulated years of breaking changes. Treat each major version jump as a separate upgrade event — jumping webpack 3 → 5 directly is not the same as reading one migration guide.

Recommended Upgrade Sequence

Phase 1 — Security patches (this week)

All packages with CVEs, regardless of how major the version bump. Security > stability.

Phase 2 — Minor and patch updates (next sprint)

# Preview what npm can safely auto-update
npx npm-check-updates --target minor

# Apply minor/patch updates to package.json
npx npm-check-updates --target minor -u
npm install
npm test

This batch is typically safe and can be done in one PR.

Phase 3 — Major version upgrades (one per sprint, one at a time)

Each major upgrade gets its own PR. Never batch two major upgrades together — if tests break, you won't know which package caused it.

Blast Radius Analysis with Lockfile Diffing

Before upgrading anything major, understand what changes in your dependency tree:

# Save current lockfile state
cp package-lock.json package-lock.before.json

# Upgrade the target package
npm install somepackage@latest

# Diff the lockfile to see ALL transitive changes
diff package-lock.before.json package-lock.json | grep '"version"' | head -40

A major upgrade to prisma@5 might quietly pull in a new @prisma/client that changes your query API. The lockfile diff shows you the full blast radius before you run a single test.

Sample Upgrade Plan

CI Integration

Make sure your CI runs the full test suite on every dependency upgrade PR. Add a job that fails if npm audit finds high/critical CVEs:

# In your CI pipeline
npm audit --audit-level=high

Also consider dependabot or renovate for automated PRs — they handle the minor/patch upgrade treadmill so you can focus engineering time on the major version work that actually needs human review.

The goal is to get to a state where you're never more than one major version behind on any critical dependency. From there, incremental upgrades are cheap. Catching up from 3+ versions behind is where the real work lives.