Keep dependencies patched

The list is always long and never empty. The goal is not zero, it is that nothing exploitable and reachable stays open, and that the rest moves steadily rather than in a panic once a year.

Steps

1. Pull the current findings for each repository and group them by package rather than by finding. One upgrade usually closes several.
2. Sort by exposure, not by the severity badge. For each high finding, answer: is the vulnerable code path something this application actually calls, and can a user reach it with input they control? A critical in a transitive package used only by a build tool is less urgent than a medium in the request path, and treating the label as the ranking is how the real one stays open.
3. Split into three batches: patch-level upgrades that nothing should notice; minor upgrades that need the test suite; and major upgrades that need reading a changelog and a person.
4. Land the first batch as one pull request. All the patch bumps together, lockfile regenerated with the repo's own tooling rather than by hand, one line per package in the description saying what it closes.
5. Land each major separately, with the breaking-change notes in the description and the parts of the codebase that touch it named.
6. For anything you are not upgrading, record why and when it will be looked at again. An accepted risk with a date is a decision. Without one it is a backlog.

Stop and ask

• Before upgrading anything across a major version in a dependency the product's behaviour rests on: the framework, the database driver, the auth library.
• When the only fix is to replace an unmaintained package. That is a project, not a patch.

Never

Turn off a scanner or add a blanket ignore to make a report green.