Read the resolved version of your library from each app's lockfile, put the results in one table with the owner and last update date, and review it on a fixed schedule. Package manifests show the range an app asked for, but the lockfile shows what it actually installs.
Why the manifest is not enough
An app's package.json might say the library is allowed within a range. The lockfile records the exact version resolved. Two apps with identical manifests can be several releases apart, because one refreshed its lockfile last week and the other last year.
For a security patch to your library, the lockfile version is the fact you need.
Build the adoption table
| Column | Why it helps |
|---|---|
| App name and repo | Lets you find it |
| Owning team and contact | Lets you ask |
| Library version in lockfile | The real status |
| Date of last lockfile change | Spots abandoned apps |
| Latest library major you support | Shows how far behind |
| Deadline and status | Turns the table into a plan |
Steps
- List the repos that depend on the library. A search for the package name across your source host is a start; a dependency inventory from your scanner is better, since it catches repos you forgot.
- Extract the version from each lockfile. A short script that parses the lockfile and prints the version for one package is enough. Keep the script in the library repo.
- Record it in a sheet or your tracking system, along with the date.
- Set a deadline per severity. Use your written policy. For routine updates, a quarterly target is common; for security patches, use your normal fix window.
- Review on a schedule. Ten minutes at the start of each release cycle is enough to keep it current.
- Chase the stragglers by name. A message to a team lead with the app name, current version and the fix link gets answers faster than a broad announcement.
Handling apps that never move
Some apps are in maintenance mode or owned by nobody. Add them to the table anyway. If no owner exists, that is a finding in itself: escalate it, decide whether to retire the app, or accept the risk in writing. The question of who upgrades is covered in who fixes a vulnerable internal shared library.
Make updating easy for them
Teams lag when upgrading is painful. Publish a short migration note with each release, state whether it is a patch, minor or major according to your versioning policy, and include a codemod when you rename things. See what is a codemod and when to use one. An update bot that opens a pull request in each app also moves the work from "someone should" to "review this".
Try it yourself
Click through it at your own pace, or open it full screen. Watch how a standing view of the estate replaces one off checks.
Safeguard's asset discovery and SBOM scanning can list which repositories and applications use a given package and version, which gives you the first two columns of the table without manual searching. A free scan is at gold.safeguard.sh/scan.
Quick check
Should I track the range or the resolved version?
Track the resolved version from the lockfile. The range only says what is allowed.
How often should the table be refreshed?
Once per release cycle is a good default, and again whenever you publish a security patch.
Last reviewed: 19 October 2026.
