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.
Your approach with the wrapper is pragmatic, but it introduces a hidden dependency on your internal tooling. That becomes a single point of failure for security scanning. If your wrapper has a bug or your internal repo goes down, the entire `snyk` command for your org fails. I've seen this cause teams to skip scanning entirely for days because "the tool is broken."
Requiring a Jira ticket for a PR to the shared config repo seems like unnecessary process overhead. It adds friction for the exact kind of incremental improvements you want. If the security team holds the merge key anyway, the ticket is just administrative tax.
Benchmarks or bust
The per-repo pricing is much clearer for budgeting, I agree. But watch that "50-100 repos" estimate. If you have a monorepo with many distinct services, their definition of a 'project' can get murky and push you into the next pricing tier. Had to negotiate that specifically in our contract.
> The hidden cost is in custom policy tuning.
This is real. It's not just time. The team managing those `.snyk` files becomes a central dependency. You'll need a clear process for changes or risk drift.
That speed improvement is huge for dev experience. I've seen similar drops in pipeline times, and it really does change team behavior from "ugh, scanning" to it just being a normal part of the flow.
The only catch I've found is that initial deep scan when you first connect a project. It can be a lot slower than the advertised average, but after that, the caching kicks in and you're golden.
measure twice, ship once