Reachability analysis mostly does not help when a package is malicious. It asks whether your code calls a vulnerable function, but malware often runs at install or import time, before your code calls anything. For a malicious release, ask whether it was installed and executed, not whether a function is reachable.
Two different questions
A vulnerability is a flaw that an attacker must reach through your code. Reachability analysis narrows a long list of advisories to the few where your code can actually trigger the flaw. A malicious release is a different case, because the author already controls the code that runs.
npm runs lifecycle scripts such as preinstall, install and postinstall of installed packages by default, unless ignore-scripts is set. That means code can run during installation, with no call from your application.
| Question | Vulnerability | Malicious package |
|---|---|---|
| Does it matter if my code calls it? | Yes, that is reachability | Usually no |
| What decides impact? | Reachable, exploitable, exposed | Installed, executed, what it could read |
| First action | Prioritise by reachability | Search, contain, rotate |
| Fix | Upgrade or mitigate | Remove, rebuild, rotate |
Where reachability still helps
- After the incident. When you move to the clean version, reachability helps prioritise the many ordinary vulnerabilities that surface in the same cleanup.
- For compromised libraries that are also vulnerable. A malicious fork may hide behind an unrelated flaw, and the flaw triage stays valid.
- For noise control. In a busy week, it keeps ordinary advisories from burying the incident work.
What to use instead
- Presence: which builds contain the version.
- Execution: did an install or build run during the window.
- Access: what secrets and data could that environment read.
- Outbound traffic: did anything leave.
See finding a compromised version across your estate.
A practical rule
Use two separate queues. The vulnerability queue is sorted by exploitability, reachability and exposure. The incident queue is sorted by execution and access. A single advisory feed will contain both kinds of item, so tag each entry on arrival. Teams that mix the queues tend to lower the priority of a malicious release because the vulnerable function is not called, which is exactly the wrong conclusion. Write the rule into your triage guide so a new analyst does not have to rediscover it during an incident.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch how reachability trims a vulnerability list, then ask whether the same logic would apply to install time malware. It would not.
Quick check
Should I mark a malicious package as not reachable and move on?
No. Reachability is not evidence of safety for malware. Check install and execution.
Is reachability still worth having?
Yes, for prioritising ordinary vulnerabilities. It is just not the tool for this question.
Safeguard includes reachability analysis for vulnerabilities and SBOM and dependency scanning for presence checks. A free scan is at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
