To see which teams lag on a shared internal library, count for each service the version it runs, compare it with the latest supported release, and group by owning team. Report the share on the fixed version and the days from release to adoption. Use it to find blockers, not to shame teams.
Three numbers
- Adoption share: services on a supported version divided by all consuming services.
- Time to adopt: days from a security release to the service running it. Report the median and the slowest.
- Version spread: how many distinct versions are live. More than three usually means an upgrade process problem.
A sample view
| Team | Services using library | On fixed version | Median days to adopt |
|---|---|---|---|
| Team A | 6 | 6 | 2 |
| Team B | 4 | 2 | 9 |
| Team C | 3 | 0 | no upgrade yet |
The numbers above are illustrative. Your own come from your inventory.
Where the data comes from
Lockfiles and SBOMs list resolved versions per service. Continuous scanning refreshes that list so it reflects what runs now, not what ran at the last build. Map each service to a team through your catalog owner field or CODEOWNERS file.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through the monitoring view and watch how findings update as components change.
Reading the result
Ask why before judging. A lagging team often has a real blocker: a breaking major, flaky tests, a frozen release period or a transitive pin. Group causes and fix the common ones centrally. If the owner's releases are hard to adopt, the metric is describing the library, not the team.
Avoid the trap
Do not turn the number into a league table. When a measure becomes a target, people optimise the measure. Pair it with the count of exceptions and their ages, so a team cannot look good by hiding blocked upgrades.
Cadence
Review monthly with team leads. After a critical release, look at it weekly until adoption reaches the target in your service level.
For the service level itself see security fix service levels for an internal library.
Safeguard can help with the inventory side: its SBOM and dependency scanning shows which services pull in a given internal library, and you can run a free scan at gold.safeguard.sh/scan.
Quick check
What is a healthy version spread?
One to three live versions. More than that suggests teams are not getting or taking upgrades.
Should the metric be public across the company?
Share it with team leads and engineering management for action. Broad publication can create defensiveness without helping.
Last reviewed: 19 October 2026.
