Take the resolved version of one dependency from every service's lockfile or SBOM, count services per version, and compare against the newest supported release. The spread is your drift. Report it for the dependencies that matter most, and set a convergence target such as "everything within one minor version".
Definition
Version drift is the gap between the versions of the same dependency in use across your services, and between those and the latest supported release. Some drift is normal. Wide drift means some services will carry fixed vulnerabilities and some will not, and every advisory becomes a fresh scramble.
How to measure
- Choose the dependencies to watch: those shared by many services, those on the internet facing edge, and those with a history of advisories.
- Extract resolved versions from lockfiles or per service SBOMs.
- Count services per version.
- Mark the latest supported release and any versions already known to be vulnerable.
- Compute two numbers: the share of services on the latest line, and the oldest version still deployed.
A table to produce
| Version | Services | Status |
|---|---|---|
| 4.2.x | 41 | current |
| 4.1.x | 23 | supported |
| 3.9.x | 6 | affected by advisory |
| 3.4.x | 2 | end of life |
The numbers above are an example of the shape and not measured data. The useful part is the last column, which tells you which rows demand action.
Reading drift
- A long tail of old versions usually means a few abandoned services. Handle them as an ownership problem.
- Two big groups on two versions usually means a stalled migration. Find the blocker.
- A uniform spread means no process. Add scheduled updates.
Closing the gap
Grouped update pull requests can reduce the review cost: GitHub's Dependabot allows grouping by dependency name across directories for version updates, if all directories share an ecosystem. Central pull requests help with shared libraries you own, but each service owner still reviews and deploys.
For stubborn services, set a deadline tied to an end of life date. After that date, a service on an unsupported version moves to the exceptions list.
Pin and update
Pinning gives reproducibility, and it means you must update on purpose. Docker's guidance on pinned bases says the same: you give up automatic security fixes, so use tooling to propose updates. Drift is what you get when pins are never refreshed.
Quick check
Is zero drift the goal?
No. The goal is a bounded spread with no known vulnerable versions deployed.
Which source is better, lockfile or SBOM?
Either works if it records resolved versions. An SBOM generated from the built artifact is closest to what actually runs.
Safeguard's SBOM and dependency scanning supports this kind of fleet view, and a free scan shows one project.
Sources
Last reviewed: 19 October 2026.
