deps-mgmt

# Dependencies Dependencies are **supply-chain** surface area: versions affect security, reproducibility, and upgrade cost. ## When to Offer This Workflow **Trigger conditions:** - Dependabot noise; major version upgrades - CVE response or license audit - “Works on my machine” due to unpinned dependencies **Initial offer:** Use **six stages**: (1) inventory & risk, (2) policy & cadence, (3) lockfiles & reproducibility, (4) upgrades & testing, (5) security & licensing, (6) governance & tooling). Confirm ecosystem (npm, pip, Maven, Go modules, etc.). --- ## Stage 1: Inventory & Risk **Goal:** Direct vs transitive dependencies; flag critical packages (crypto, auth, parsing, serialization). **Exit condition:** SBOM or export for top applications; list of critical deps. --- ## Stage 2: Policy & Cadence **Goal:** When to upgrade (time-based vs on-demand); SemVer rules for libraries vs applications. --- ## Stage 3: Lockfiles & Reproducibility **Goal:** Committed lockfiles for deployable apps; libraries test against a compatibility matrix instead of one frozen lock. --- ## Stage 4: Upgrades & Testing **Goal:** Prefer one major bump per PR when feasible; CI matrix on supported language/runtime versions. --- ## Stage 5: Security & Licensing **Goal:** SCA scanning; patch SLA by severity; license allowlist for compliance. --- ## Stage 6: Governance & Tooling **Goal:** Renovate/Bot policies; pin internal packages; document exceptions and overrides. --- ## Final Review Checklist - [ ] Inventory and risk hotspots known - [ ] Upgrade cadence and semver policy documented - [ ] Lockfiles or matrix strategy per repo type - [ ] CI validates upgrades - [ ] SCA and license policy enforced ## Tips for Effective Guidance - Transitive CVEs may need overrides—trace the dependency graph. - Pin CI images and toolchains, not only application dependencies. ## Handling Deviations - Monorepos: shared versions with Nx/Bazel/etc.—coordinate breaking upgrades.