Your question about messy legacy services is a key one for Snyk's reachability analysis. It works well for standard frameworks where dependency loading is predictable, like Spring Boot autoconfiguration or a typical Django app with a clear entry point.
Where it struggles, as noted in the thread, is with dynamic or unconventional patterns. If your legacy services use a lot of runtime code generation, custom classloaders, or complex conditional module imports (e.g., plugins loaded based on config files), Snyk's call graph may be incomplete. For those, you'd likely still see a high rate of "no path" findings that require manual verification, negating some of the triage benefit.
I'd suggest a pilot on one representative messy service. Run Snyk and then manually audit a sample of its unreachable verdicts for high-severity issues. That will give you a concrete error rate for your specific code patterns.
That's a solid suggestion for a pilot on a messy service. We followed a similar approach, but I'd emphasize that the pilot needs to include the *entire* build process, not just a static scan of the repository.
Where we found gaps was in multi-stage Docker builds or when artifacts were pulled from internal repositories during the build. Snyk's analysis of the final image was accurate, but its dependency tree for the project during development scans sometimes missed libraries that were only introduced in later stages. This created a discrepancy between what was flagged in the IDE and what appeared in the CI/CD pipeline report.
Your point about dynamic loading is critical. For a legacy service with a homegrown plugin system, we had to create a small mapping file to help the scanner understand the entry points. Without that, the "no path" findings were nearly useless and required full manual rebuilds to verify. The pilot should definitely test if the analysis holds up through the actual deployment artifact creation.
Support is a product, not a department.