Dependency update lag measures how far each dependency version in use trails the newest available one, in releases or in time. It is a leading indicator: the further behind you are, the bigger the jump when an urgent security fix lands. It is easy to compute from your lock files and registry data.
What to measure
Choose one or two simple forms:
- Major versions behind. Zero, one, two or more.
- Age gap. Days between the release you use and the latest release.
- Share of direct dependencies more than a year behind.
Pick forms that you can compute reliably from lock files and the registry of each ecosystem. Compute per service, then roll up.
Why it matters for exposure
When an advisory appears for a package, the cost to fix depends on the version gap. A patch release is a small change. If the fixed version is two majors ahead of yours, the fix is a migration, and the exposure window stretches while that project is planned.
Keeping lag low turns future urgent fixes into routine updates. This is a quiet way to shorten exposure windows before any vulnerability exists. For measuring the window itself, see exposure window start and end points.
Direct and transitive
Direct dependencies are the ones your team chose, so lag there is a team decision. Transitive dependencies often follow when you update the direct ones, but sometimes they are pinned by an intermediate package. Report both, and list the direct package responsible for the oldest transitive ones. That gives a developer something to act on.
Abandoned packages
Update lag can mislead when the package is no longer maintained: you are on the latest release, but the latest is years old. Add a second flag for packages with no release in a long period you choose, such as two years, and treat those as replacement candidates. Do this as a flag, not a verdict, because some stable libraries are simply finished.
Setting a goal
Do not aim for zero lag everywhere. Pick a policy such as "no direct dependency more than one major version behind on internet facing services" and track compliance. Goals tied to a specific tier of service are easier to defend.
Making updates routine
Small, frequent updates with tests are easier than large annual ones. Automated update proposals reviewed by a human help, and Safeguard's autonomous remediation can open fix pull requests, off by default with every category on Manual until you turn it on.
You can see what dependencies in a project are behind or vulnerable by running a free scan.
Quick check
Is update lag the same as vulnerability count?
No. You can be far behind with no known vulnerability, and current with one. Lag predicts effort, not present risk.
Should we always update to the newest version?
Not blindly. Read release notes and test, and consider a short soak period for major releases.
Last reviewed: 19 October 2026.
