G2

Yurii L.

.NET Technology Lead

Information Technology and Services

Mid-Market (51-1000 emp.)

9/8/2026

"Security findings started showing up where developers could actually fix them"

4.5/5

What do you like best about Snyk?

For our .NET work, Snyk became much more useful once we stopped treating security as something that happens after development. Snyk Open Source integrates well with NuGet and Paket, understands project.assets.json, solutions, and project files, and can generate Fix PRs for supported NuGet dependencies. That alone saves us from discovering vulnerable packages during a later audit, when the person who introduced the dependency may not even be on the same project anymore. We also use Snyk Code for SAST across C# and VB.NET. In one review, it traced a request value through several methods until it reached a database query that didn’t have enough sanitization. Being able to see the full source-to-sink path was far more useful than a generic “possible SQL injection” warning that gives no clue how the value got there. Inter-file analysis is especially important in .NET because the risky part rarely lives in the same method where the input first enters the application. In CI, we run snyk test and snyk code test, and the IDE plugin catches many issues before a pull request even exists. That combination has done more for adoption than any security dashboard. Developers respond much better when a finding shows up right next to the code they’re already changing, instead of arriving three weeks later in a spreadsheet from another team. Review collected by and hosted on G2.com.

What do you dislike about Snyk?

Some dependency setups require pinning explicit versions to get Fix PRs to work. Also, packages-lock.json isn’t supported by Snyk Open Source, and legacy projects may fall back to static resolution, where private dependencies or build-specific behavior are harder to capture accurately. None of this has stopped us from using the tool, but older solutions still need more manual verification than modern SDK-style projects. I’d like the gap between a current ASP.NET Core service and a mixed legacy repository to be smaller, especially when both live in the same organization and are expected to follow the same security policy. Review collected by and hosted on G2.com.

What problems is Snyk solving and how is that benefiting you?

We ran into this trade-off during a release of an ASP.NET Core billing service, right after several NuGet upgrades and a container base-image change. Snyk Open Source flagged a critical vulnerability in a transitive dependency and indicated that an indirect package update could remove it. At the same time, Snyk Code identified an unsafe data flow in a new endpoint, and Snyk Container surfaced vulnerable packages inherited from the base image. Our first instinct was to stop the release entirely, which would have been the safe-looking answer but not necessarily the right one. We reviewed reachability and the actual execution path and determined that one finding couldn’t be reached from our application configuration, while the other two represented real exposure. We upgraded the package, switched the base image, fixed the endpoint, and reran the pipeline before deployment. Afterward, we kept the same checks on pull requests so these issues would be caught closer to the change, instead of turning into another release-day surprise. Snyk gave us enough context across code, dependencies, and containers to tell the difference between something that can be scheduled and something that truly needs to block production. Review collected by and hosted on G2.com.