Acceptable is any release the maintainers still support with security fixes, as long as the latest patch in that line is installed. Set the limit by support status, not by how new the version is. Write a maximum lag for major versions and a faster limit for security patches.
Why newest is the wrong target
Always chasing the latest release adds churn and exposes you to freshly published code before the community has had time to notice a problem. Falling years behind has the opposite cost: fixes pile up, upgrades get harder and eventually no one can upgrade safely.
A policy based on support status avoids both. Stay on a line that receives security fixes, apply patches promptly, and plan major upgrades before support ends.
Three rules to write
| Rule | Example wording to adapt |
|---|---|
| Patch rule | Security patch releases for a supported line are applied within the time set for the finding's severity |
| Support rule | Production code must use a release line that the maintainers still support with security fixes |
| Major rule | Major versions are reviewed at least once a year, and no more than a set number behind latest without an exception |
Pick numbers that fit your delivery speed. If you ship monthly, a yearly major review is realistic. If you ship twice a year, adapt.
How to know support status
Check the project's own release or support page, which is the authority. Some projects publish a table of supported lines and end dates. Others have no formal policy, in which case treat only the latest line as supported and say so in your record.
If a project does not state support, that is itself a risk signal for intake.
Handling the awkward cases
- A security fix exists only in a new major version. Treat the upgrade as a security change with its own deadline, and open a work item with owner and date.
- The supported line has ended and you cannot move. File an exception with an expiry date and compensating controls.
- A patch release changes behavior. Run the test suite, and use staged rollout for high risk services.
Automate the boring part
Use automated update pull requests for patches and minors, with required tests. Some update tools can delay new releases by a set period, which gives time for problems in a fresh release to surface. Ask for a human only for major versions.
Measure it
Track the share of production dependencies on unsupported lines and the age of the oldest unpatched security fix. Both numbers are easy to explain to leadership.
Quick check
Should we pin exact versions?
Pin through a lockfile for builds, and let automated pull requests move the pins on a schedule. That balances repeatability and freshness.
What if the project has no support policy?
Treat that as a risk factor at intake and plan for replacement or an internal owner who can patch.
Safeguard scans dependencies and builds SBOMs, runs reachability analysis, and applies policies and gates on pull requests, so the rules in this post can be checked automatically. Autonomous fix PRs are off by default, with every category on Manual. You can run a free scan at gold.safeguard.sh/scan.
Last reviewed: 19 October 2026.
