Scanners flag a dependency as vulnerable whenever a vulnerable version is present. Several vendors say most of those alerts don't matter because the application never calls the vulnerable code, and quote figures anywhere from 60% to over 98%. I wanted to see what that looks like when someone measures it independently.
I used Go, the one ecosystem whose official vulnerability database records which functions are vulnerable, and its tool govulncheck checks whether those functions are actually called. I fixed the design and thresholds in advance, scanned randomly chosen modules published in one week of August 2026, got 105 with relevant findings, then checked forty by hand against the source. Of 1,442 findings with function-level data, about one in five, 20.3%, involved a vulnerable function the module actually calls, and most of the rest, 58% of all findings, never even imported the vulnerable package. By hand, none of 30 "not called" findings turned out to be reachable in production code.
The catches matter more than the headline. Two Go project libraries supply most of the findings, and taking the Go project's x libraries out lifts the called share to 46.7%, with a margin from 40.8% to 52.6% that crosses half. Four in five database entries have no function-level data, so they can't be tested this way, and more than half the sampled modules couldn't be scanned at all. I didn't vary Go's build tags, so code behind an unset tag was never analysed, and nobody has measured how often Go projects load code through the plugin package, which the scan can't see either. Of 10 "called" findings the tool's reported path was only clearly right in 4.
So most findings with function-level data are unreachable in this Go sample, but nowhere near the 90% or more some vendors claim, and on the subset without the x libraries it's close to a coin flip. "Not called" also isn't the same as "cannot be exploited", which I didn't test. Reachability helps you prioritise. It isn't a reason to ignore findings.