Run one short, repeatable routine each week: triage new advisories, update the affected packages in a targeted way, let locked CI confirm the result, review the diff, and record what you decided. The routine is the same in every language. Only the update command differs, and most ecosystems let you update a single package.
The routine in five steps
- Triage (10 minutes). Open the shared report and sort by repo owner. Mark each new finding as fix now, schedule, or accept with a reason.
- Targeted update (15 minutes). Update the specific package, not the entire tree.
- Locked CI (automatic). Pull request CI installs in locked mode, runs tests and audit.
- Review (15 minutes). Read the lock diff. It should show the package you meant to change and its direct consequences.
- Record (5 minutes). Note the decision on any finding you did not fix.
Targeted updates in several tools
Each of these is documented by the tool maker:
| Ecosystem | Update only what you mean to |
|---|---|
| Composer | Name the package when running update, so only it and what it needs change |
| Gradle | Run the dependencies task with update-locks and a module name, with wildcards supported in group or name |
| npm | audit fix with the package-lock-only option updates only the lockfile, not node_modules |
| Cargo | See the Cargo update command documentation for limiting an update to one crate |
| NuGet | Changing a package version in the project updates the lock when restore re-evaluates it |
The Composer docs show updating a single package by naming it. Gradle's locking docs describe the update-locks option for selected modules, and note that Gradle does not write lock state if the build fails. The npm audit docs say that audit fix runs a full install under the hood, that some issues cannot be fixed automatically, and that the force option can install semver-major updates that may break things.
Reading the lock diff
A good diff touches the lockfile and the manifest together. Warning signs:
- Hundreds of unrelated version changes from a one package update.
- A new package that nobody asked for, especially one with install scripts.
- A change in a hash or source for a version that did not change.
What to do about major upgrades
Do not bundle them into the weekly routine. Open a separate ticket with a time box. Weekly updates should be small enough to merge the same day.
Keeping it going
The routine holds only if someone runs it. Put it on a calendar, name a rotating driver, and make the output a short note, not a report. After a month, count how many weeks it actually ran. If it is under three of four, the routine is too heavy: cut a step.
Safeguard can help here: it scans dependencies and generates SBOMs, applies reachability analysis so you can sort findings by what your code can actually call, and enforces policies and gates on pull requests. You can try a free scan on a repository to see what it finds.
Try it yourself
Open the demo and look at how a fixed version is surfaced for a finding, which is the starting point of a targeted update.
Click through it at your own pace, or open it full screen.
Quick check
Should the weekly routine update everything?
No. Update what advisories or policy call for, in small changes, so each diff is easy to review.
Does npm audit fix change only the lockfile?
Only if you use the package-lock-only option. Otherwise it runs a full install, per the npm docs.
Sources
Last reviewed: 19 October 2026.
