Search the dependency data for every service, not the source code. Query lockfiles or SBOMs for the package name, record the resolved version and whether it is direct or transitive, then confirm which of those versions are actually deployed. The result is an affected list you can rank by exposure and send to owners.
Why grep is not enough
A text search for the library name finds direct dependencies in manifests. It misses transitive ones, where another package pulls the library in, and it misses services whose lockfile pins a different version than the manifest range suggests. It also finds repos that never ship.
Step by step
- Define the question precisely: package name, ecosystem, and the affected version range from the advisory.
- Query per service dependency data, such as lockfiles or SBOMs, for that package.
- Record, for each hit, the resolved version, the path that brought it in, and the manifest or file.
- Compare the resolved version against the affected range. Drop the services already on a fixed version.
- Check the deployed artifact. A repo on a fixed version means nothing if production still runs last month's image.
- Rank what is left by exposure, lifecycle and data sensitivity.
- Send each owner a short list: service, version, path, fixed version.
A worked table shape
| Service | Resolved version | Path | Deployed? | Exposure |
|---|---|---|---|---|
| checkout-web | 2.3.1 | direct | yes | internet |
| report-worker | 2.3.1 | via formatter-lib | yes | internal |
| old-admin | 2.1.0 | direct | no, retired | none |
Names here are invented to show the shape. The point is that each row says how the library arrived, so the fix path is clear. A direct dependency needs a bump. A transitive one needs the parent bumped, or an override if your package manager supports it.
Reachability changes the order, not the list
Every affected service stays on the list. Reachability analysis helps decide which one to fix first, by showing whether your code actually calls the vulnerable function. A service that imports the package but never reaches the affected code is lower urgency, not zero.
Keep the receipt
Save the query and its date. When someone asks "were we exposed on the 12th", you want an answer from data, not memory. If you generate SBOMs on every build, you get this history for free.
Try it yourself
Click through it at your own pace, or open it full screen. Watch how a component links back to every project that includes it.
Quick check
Is the lockfile or the manifest the better source?
The lockfile, because it holds resolved versions. A manifest holds ranges.
What if a service has no lockfile?
Treat it as a gap to fix. Until then, scan the built image or artifact instead.
Safeguard's SBOM and dependency scanning and reachability analysis are built for this question, and you can run a free scan on one repository.
Last reviewed: 19 October 2026.
