To find every app that uses a vulnerable library, search the dependency files of all your projects for that library's name and version, including the indirect ones. A searchable inventory built ahead of time answers in minutes. Without one, you search repository by repository and may miss some.
TL;DR
- The hard part is not the fix. It is knowing where the library lives.
- A library can hide as an indirect dependency, deep in a tree you never read.
- Search the lockfile, not just the manifest, because it lists exact versions.
- Build a standing inventory now, so the next announcement takes minutes.
- After you find the apps, rank them by exposure and fix the most exposed first.
Why is this question so hard to answer?
Definition: A software inventory is a searchable list of the components inside each of your applications, with their versions. It lets you answer "where do we use X?" without opening every project by hand.
Picture a recall on a single car part. The maker knows which factory batch used the part, and which cars were built from that batch. Because the records exist, the recall letters go out quickly. Now picture a maker with no records. Someone has to open every car to check. That is where many software teams are when a new flaw is announced.
There are three reasons it is hard.
- Many projects. Companies often have dozens or hundreds of repositories, owned by different teams.
- Indirect use. You may never have chosen the library. Another package brought it in. If you want to see how that happens, read why apps have hundreds of dependencies.
- Different places. The library may sit in a web app, a background job, a container image, or a mobile build.
The OWASP Top 10 puts the root cause plainly. It says you are likely vulnerable if you do not know the versions of all components you use, including nested dependencies. And its fix is to continuously inventory the versions of components and their dependencies, and to monitor sources such as the CVE list and the National Vulnerability Database for problems in them. An inventory is the answer to this exact question.
What is the quick, manual way to search?
If you have no inventory, do this. It is slow but it works.
- Write down the exact name and the affected versions. Read the advisory carefully. It will say which versions are affected and which are fixed.
- List your repositories. Include old and quiet ones. Forgotten projects are often the ones left unpatched.
- Search each lockfile. The npm documentation says the lockfile describes the exact tree that was generated, so it is the best file to search. A manifest alone shows only the packages you chose, not the ones they brought in.
- Record the version you find. Not every use is affected. Only the listed versions are.
- Check build outputs too. Container images and packaged apps may contain a different version than the source does.
- Make a list with owners. For each hit, note the team that can fix it.
This takes hours for a handful of repositories and days for hundreds. It also depends on people remembering every project. That is why most teams eventually move to a standing inventory.
What does a standing inventory look like?
A standing inventory is built before the emergency. Every time a project builds, a tool records the full list of components and stores it in one place you can search. Many teams store it in a standard format called an SBOM, short for software bill of materials. If the term is new, read what is an SBOM.
The table compares the two approaches.
| Question | Search by hand | Standing inventory |
|---|---|---|
| How long to answer "where is library X?" | Hours to days | Minutes |
| Finds indirect uses | Only if you read lockfiles | Yes, if it reads the full tree |
| Finds forgotten projects | Only if you remember them | Yes, if every project is connected |
| Shows the version in use | Per file, by hand | In one list |
| Shows who owns it | You have to ask | If ownership is recorded |
| Stays current | Goes stale | Updates with each build |
An inventory is only as good as its coverage. A project that is not connected is invisible. When you set one up, start with the projects that face customers, then add the rest.
How do I rank the hits once I have them?
A list of 40 affected projects is not a plan. Rank the hits.
- Internet facing first. An app any visitor can reach is more exposed than an internal tool.
- Is the vulnerable part used? A library can be present without its flawed function being called. This is called reachability. See the reachability analysis FAQ.
- Is it being exploited? The Cybersecurity and Infrastructure Security Agency keeps a catalog of vulnerabilities known to be exploited in the wild and recommends using it as an input to prioritization. If your flaw is on it, move faster.
- What data is at risk? An app that holds customer records ranks above one that holds only public pages.
- How hard is the fix? Quick wins can ship the same day while harder ones get scheduled.
The CVSS, EPSS and KEV FAQ explains the scoring signals in more detail.
A worked example with invented numbers
All numbers here are invented to show the method. The library name is made up.
An advisory says versions 2.0 to 2.4 of a library called "imagetool" have a serious flaw. Version 2.5 is fixed. You have 30 repositories.
- You search all 30 lockfiles. The library appears in 9 of them.
- In 5 of those 9, the version is in the affected range. In the other 4, it is already 2.5 or newer.
- Of the 5 affected, 2 are customer facing, 1 is an internal admin tool, and 2 are old batch jobs.
- In 4 of the 5, the library arrived as an indirect dependency.
Your plan: fix the 2 customer facing apps today. Fix the admin tool and the batch jobs this week. For the 4 indirect cases, upgrade the parent package that brings the library in, and confirm with a rescan.
Without an inventory, finding those 5 might take a day. With one, it took the time to type one search. That difference is what matters when a flaw is being exploited.
What should I record so the next time is faster?
- Every project, including quiet ones, connected to the inventory.
- An owner for each project, so a hit goes to a real person.
- A way to search by library name and by version range.
- A rule to rescan on a schedule, because new flaws appear after a build is finished.
On that last point, see the note in the first scan guide: a scan is a snapshot, and a scan done last month cannot know about a flaw published this morning. That is why the inventory should be checked again against fresh vulnerability data, not only built once.
Try it yourself
The demo below shows a vulnerability queue for a product across all of its projects in a sample workspace. Click through and look for how one view covers every project, and how each finding carries a status.
Click through it at your own pace, or open it full screen.
Quick check
Is searching package manifests enough?
Not usually. Manifests list only the packages you chose. Lockfiles and full scans list indirect dependencies too, and those are often where the vulnerable library hides.
What if the library is only in a container image?
Then search image contents too, not only source repositories. The version inside a built image can differ from what the source files show.
Do all hits need an urgent fix?
No. Only versions in the affected range count, and then you rank by exposure, whether the vulnerable code is reachable, and whether the flaw is being exploited.
How can Safeguard help with this?
Safeguard's SBOM and dependency scanning builds a component inventory for each project and rechecks it against vulnerability data, so you can ask where a library is used across projects. Asset discovery helps you find the systems you may have forgotten. Reachability analysis helps you rank hits by whether your code can actually call the flawed part.
If you want to see your own inventory, run the free scan at gold.safeguard.sh/scan.
Sources
- OWASP Top 10 2021, A06 Vulnerable and Outdated Components (source text on GitHub)
- npm Docs: package-lock.json
- CISA Known Exploited Vulnerabilities Catalog
Last reviewed: 19 October 2026.
