To find every place a compromised package version is used, search five places for the exact name and version: lockfiles in source control, SBOMs for released builds, container images in your registry, CI and package proxy caches, and developer machines. Lockfiles alone miss what was already built and shipped.
Know what you are searching for
Get the package name, the affected version list and the publish window from the registry advisory or maintainer notice. If the advisory gives a range, list the versions explicitly. A search for the name alone returns safe versions and creates noise.
Where to look
| Place | What it tells you | How to search |
|---|---|---|
| Lockfiles | What new builds would install | Search every repo and branch for the name and version |
| SBOMs | What a released build contained | Query stored SBOMs by component and version |
| Container images | What is running or deployable | Scan images, or search their SBOMs |
| Proxy and CI caches | What was fetched during the window | Check proxy download logs and cache contents |
| Developer machines | What was installed locally | Check global installs and local node_modules |
Steps
- Write down the exact versions and the time the bad release was published and removed.
- Search all branches, not only the default branch. Old release branches often hold old lockfiles.
- Search transitive entries. A lockfile lists indirect dependencies, and that is where most hits hide.
- Query stored SBOMs for released artifacts, since a lockfile on main today may differ from what shipped last month.
- List images by digest and check each. A tag can point at different content over time, which is why digests matter. The Docker CLI can show the manifest and digests for an image without pulling it.
- Check the package proxy or mirror log for downloads of the bad version during the window. A hit means someone installed it even if no lockfile mentions it.
- Record each hit with owner, environment and whether it was deployed.
Common gaps
Monorepos hide extra lockfiles in sub folders. Projects with no committed lockfile resolve versions at install time, so a build during the window may have picked the bad release with no trace in source control. Build logs from that period are then your evidence.
For more on inventory based response, see finding affected products fast with SBOMs.
Try it yourself
Click through it at your own pace, or open it full screen.
Search the inventory for a package and see which projects carry it, direct and indirect.
Quick check
Is a lockfile search enough?
No. It shows what future builds install, not what past builds shipped. Add SBOMs, images and proxy logs.
What if we have no lockfile?
Use build logs and proxy download records for the window, and treat any build in that period as possibly affected until shown otherwise.
Safeguard's SBOM and dependency scanning can list which projects use a component and version. A free scan is available at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
