A package can be installed, imported or executed, and each is a different level of use. Scanners usually flag installed packages. Real exposure needs the vulnerable code to be imported and then run with input an attacker can influence. Knowing which level applies decides whether a finding is a false positive.
Three levels, defined
Installed. The package appears in your lockfile or on disk. It may have arrived as a dependency of a dependency. Nothing in your code needs to mention it.
Imported. Some code in your project, or in a package you load, pulls in the module. It is now loaded into memory when that code path runs, though loading is not the same as calling its risky parts.
Executed. The specific function, class or setting named in the advisory actually runs in a deployed process, ideally with data from outside.
| Level | Typical evidence | Is a finding likely a false positive? |
|---|---|---|
| Installed only | Lockfile entry, no import found | Often, but check install scripts |
| Imported | An import statement or require call | Maybe: depends on the function |
| Executed | Call path from an entry point | Probably real |
Why the distinction matters
An advisory almost always names a specific function, parsing mode or feature. Installed alone does not trigger it. Imported alone usually does not either. The risk begins when that named part runs.
That is why reachability analysis exists: it asks whether a path leads from your code to the vulnerable function. Our post on reachability for triage covers the method.
Cautions on the installed only case
Do not wave away installed only packages too fast.
- Install scripts. Some ecosystems run scripts at install time, so an installed package has already executed something on your build machine.
- Dynamic loading. Code that loads modules by name at runtime defeats simple import searches.
- Plugins and reflection. Frameworks can pull in classes by configuration.
If any of these apply, record that you checked them.
A fifteen minute check
- Search the repository for imports of the package name, and for its exported names.
- Check which of your dependencies import it, using the dependency tree.
- Read the advisory for the exact vulnerable function or option.
- Search for that function or option in your code and in the importing dependencies.
- Note what you found, with the commands, in the suppression record.
Try it yourself
Click through it at your own pace, or open it full screen. Look for how the demo separates a package being present from a vulnerable path being usable.
Where Safeguard fits
Safeguard combines SBOM and dependency scanning with reachability analysis, so each finding shows whether code is only present or actually reachable. Try a free scan at gold.safeguard.sh/scan.
What to write down
Whichever level you find, write it into the record in one line, such as installed only, no import found, no install script. That line is what a later reviewer needs to trust the decision.
Quick check
Is an unused dependency safe to ignore?
Usually lower risk, but remove it. Check install scripts and dynamic loading first, and delete it rather than suppress it when you can.
Does an import mean I am vulnerable?
Not by itself. The advisory usually names a specific function or option that must run.
Last reviewed: 19 October 2026.
