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.