Finding things
Reachability
Most vulnerable packages sit in code the application never calls. This says which, and says why on every finding.
Three questions, not a call graph
Is the package asked for directly or is it eleven levels down. Is it a development dependency that never ships. Is the vulnerable module imported anywhere in the source at all. A full call graph is a large piece of work and the wrong first step; these three are facts about the tree and they get most of the way.
What it does to a list
On a corpus of three hundred and sixty one dependency findings, two hundred and seventy eight came back as not reached, each with a sentence: a development dependency that does not ship, or nothing in the source imports it. The remaining eighty three are a list somebody can work through.
When unsure, keep
Where it cannot tell, the verdict is unknown and the finding keeps its place. A wrong "unlikely" is somebody not looking at the one that mattered, so the rule is deliberately asymmetric.
What it does not do
A heuristic, and it says so. Snyk builds a call graph and can tell you the vulnerable function is reached rather than merely the package. That is a stronger claim than this makes.
Every feature page carries one of those. The comparison page scores the same ground against five products people pay for, including the rows that go against us.