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

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

1. If this dependency disappeared tomorrow, how hard would it be to replace?
2. What exactly do we use from this dependency? (list specific functions/features)
3. Could we implement this ourselves in less than 100 lines?
4. Who maintains this? Is it one person or an organization?
5. When was the last release? When was the last commit?
6. Does this dependency pull in heavy transitive dependencies?
7. Is the license compatible with our project?
8. What's our update strategy for this dependency? (auto / manual / pinned)
9. If this dependency has a breaking change, how much of our code changes?
10. Are there lighter alternatives that cover our specific use case?

1. LIST all direct dependencies and their versions
2. COUNT total dependencies (direct + transitive)
3. IDENTIFY outdated packages (how far behind latest?)
4. FLAG deprecated packages
5. IDENTIFY duplicate packages (same package, different versions)
6. CALCULATE total dependency weight (disk size, download size)

# Node.js
npm ls --all --depth=0          # Direct dependencies
npm ls --all | wc -l            # Total dependency count
npm outdated                     # Outdated packages
npx depcheck                     # Unused dependencies

# Python
pip list                         # All installed
pip list --outdated              # Outdated packages
pip show [package]               # Package details
pipdeptree                       # Dependency tree

# General
du -sh node_modules/             # Total size (Node)
find node_modules -name "package.json" | wc -l  # Package count (Node)

# Run the appropriate audit command
npm audit                           # Node.js
pip audit                           # Python (pip-audit)
bundle-audit check                  # Ruby
composer audit                      # PHP
cargo audit                         # Rust
dotnet list package --vulnerable    # .NET

Is it Critical or High severity?
├── Yes → Is there a fix available?
│   ├── Yes → Upgrade immediately
│   └── No → Is it exploitable in your context?
│       ├── Yes → Find alternative dependency or implement workaround
│       └── No → Document risk, monitor for fix, set review date
└── No (Medium/Low) → Schedule for next dependency update cycle

1. WHAT does it do that we actually use?
2. HOW MUCH of it do we use? (% of API surface)
3. COULD we implement this ourselves? (< 100 lines = do it yourself)
4. IS there a smaller alternative?
5. COULD a native platform API replace this? (fetch vs axios, Intl vs moment)
6. IS it a direct dependency or should it be a dev dependency?

# Node.js - List all licenses
npx license-checker --summary

# Check for problematic licenses
npx license-checker --failOn "GPL-3.0;AGPL-3.0"

1. ARE lockfiles committed? (package-lock.json, yarn.lock, poetry.lock)
2. ARE dependency versions pinned? (exact versions, not ranges)
3. IS there a .npmrc or pip.conf restricting registries?
4. ARE pre/post install scripts reviewed? (npm scripts can execute arbitrary code)
5. IS there a policy for reviewing new dependencies before adding?
6. ARE you using a private registry or proxy? (Artifactory, Verdaccio)
7. IS two-factor authentication enabled on your npm/PyPI account?

# Dependency Audit: [Project Name]

## Summary
- **Direct Dependencies:** N
- **Total (with transitive):** N
- **Outdated:** N (N critical behind)
- **Deprecated:** N
- **Known Vulnerabilities:** N (N Critical, N High)
- **Unused Dependencies:** N
- **Total node_modules Size:** XMB

## Vulnerabilities
| Package | Severity | CVE | Fix Available | Exploitable | Action |
|---------|----------|------|-------------|------------|--------|
| express | 🔴 Critical | CVE-2024-XXXX | ✅ v4.18.3 | Yes | Upgrade now |

## Health Assessment (Top 10 Dependencies)
| Package | Version | Last Published | Contributors | License | Assessment |
|---------|---------|---------------|-------------|---------|------------|
| react | 18.2.0 | 2 months ago | 100+ | MIT | 🟢 Healthy |

## Unnecessary Dependencies
| Package | Reason | Alternative | Savings |
|---------|--------|------------|---------|
| moment | Deprecated | dayjs | ~280KB |
| lodash | Only uses _.get | Optional chaining | ~60KB |

## License Compliance
| License | Count | Risk |
|---------|-------|------|
| MIT | 45 | 🟢 |
| Apache-2.0 | 12 | 🟢 |
| GPL-3.0 | 1 | 🔴 |

## Findings
[Standard severity format]

## Verdict: [PASS / CONDITIONAL PASS / FAIL]