Snyk Runtime Sensor
Clear Visibility Into Deployed Code That Strengthens Security Confidence
Seamless Dev-First Security with Fast Scans and Actionable Fixes
Performance-wise, scans run fast even on large monorepos, and the dashboard stays responsive without lag, it never feels like a bottleneck in the CI pipeline.
On pricing and ROI, the value becomes clear quickly. Catching vulnerabilities pre-deployment rather than post-production saves significant incident response costs, and the free tier is generous enough for smaller teams to see real value before committing. Onboarding was smooth too, connecting GitHub repos took minutes and gave us an immediate risk picture. It feels like a security tool built for developers, which makes adoption across engineering teams much easier.
Pricing can become a pain point as teams scale. The jump between tiers feels steep, and some features that feel essential, like deeper reporting or SSO, are locked behind higher plans, which can be frustrating for mid-sized teams trying to justify the upgrade.
Occasionally the fix suggestions aren't actionable because the recommended version introduces breaking changes, so you still end up doing manual research. It would be more helpful if Snyk flagged compatibility risks alongside the fix recommendation. The Snyk Code (SAST) results can also feel less mature compared to the SCA side, more false positives and less context around why something is flagged.
Overall these are manageable drawbacks, but they do add friction for teams trying to run lean.
The biggest benefit has been reducing the gap between vulnerability discovery and remediation. Developers get context-rich alerts in their IDE and PRs rather than a spreadsheet from a security team weeks later, which means fixes happen faster and with less back-and-forth.
It also solves the visibility problem across open source dependencies. With complex dependency trees, it was previously difficult to know what you were actually running in production and whether it was safe. Snyk gives a clear, continuously updated picture of that risk without requiring manual audits.
From a team dynamic standpoint, it bridges the gap between developers and security teams by speaking the developer's language, showing fixes, not just findings. This has made security a shared responsibility rather than a blocker, which speeds up release cycles without compromising on risk management.
The ROI shows up in avoided incidents, faster PR cycles, and less time spent in reactive fire-fighting mode, all of which compound over time.
Seamless DevSecOps with Smart PR Patching and Actionable Vulnerability Insights
Great UI and Deep Reviews, but False Positives and Too Much Detail
Easy Setup and Trusted Vulnerability Scanning
Effortless Vulnerability Detection, But Licensing Needs Attention
Automated security checks have blocked critical code issues and protect daily banking releases
What is our primary use case?
We are a customer of Snyk, which is a SaaS solution. We are one of the tenants using Snyk services but are not doing any enhancement development. We are purely a customer availing Snyk services.
We are also using a separate DAST tool, though I am not aware of the tool name as it is managed by a different team.
We utilize two main capabilities: application vulnerability detection and SCA capabilities. The primary reason we use Snyk is for SAST, as we want to scan our applications for any security vulnerabilities and address them.
What is most valuable?
Snyk is finding all the issues we have. It suggests solutions for every vulnerability, and we are getting patches frequently. As someone from an enterprise, I want to share feedback that might help others. There are multiple teams involved in our organization. We have a separate cyber team that works with Snyk and keeps on updating, though I am not fully aware of all the details in that area.
What needs improvement?
I have not explored from that perspective. Being from an application perspective, I cannot say anything that needs real improvement. I have not explored from that angle. Till now, we did not face any scaling issues and I did not hear of any. I would rate this at 9 because I always keep one number in reserve, as there is always scope for improvement for any tool.
For how long have I used the solution?
We have been using Snyk for more than a year.
What do I think about the scalability of the solution?
Till now, we did not face any scaling issues and I did not hear of any. I would rate this at 9 because I always keep one number in reserve, as there is always scope for improvement for any tool.
How are customer service and support?
We do not raise issues directly with Snyk. We have a common team that liaises with Snyk. Whenever we have issues, we raise them with the cybersecurity team within our company who supports Snyk, and they in turn interact with Snyk.
Which solution did I use previously and why did I switch?
Earlier, I used Checkmarx, which is another SAST tool. By default, any company and any SAST tool like Checkmarx or Snyk provides a plugin.
What about the implementation team?
Snyk is integrated. I have not used it directly, though I may have used it indirectly.
What other advice do I have?
I am from an enterprise and want to share feedback that might help others. There are multiple teams involved in our organization. I am from the application team, so I know the vulnerabilities and how to fix them. However, there is a platform team that takes care of giving permission for Snyk and access levels, which I am not fully aware of. At a high level, we have a Snyk admin team in our company that gives permissions, though I do not know all the details of what they do. I cannot share feedback on the admin area, but I can share that vulnerability-wise, I am happy with what Snyk provides and the solutions it gives.
When Snyk identifies issues, our pull request process will not allow us to merge them in the first place. Snyk helps us by blocking critical issues and vulnerabilities. If someone bypassed the pull request check, we have another check in place before production release where we validate everything and block the code if it violates our standards. Based on Snyk categorization, we block issues from our end while raising a pull request and also before releasing to production.
We need Snyk because we are in the banking industry with thousands of applications. Every day, we deploy code to production, releasing almost every day except weekends, though we sometimes release on weekends for very large deployments. Anything that goes to production should not have any security vulnerabilities. Being in the banking industry and having applications used by end customers, we are dealing with end customer data. No one should steal data in any format, and with authentication, one user cannot see another user's data. Snyk is paramount and extremely important for us. Every application that goes into production must pass Snyk vulnerability scanning before it can be deployed. If you ask whether it is important, it is absolutely critical. I would rate it 10 out of 10.
Internally, whenever a Snyk scan runs, we have created GitHub Actions. Our target state is GitHub Actions everywhere. When we run the GitHub Actions, it will connect to the latest Snyk scanning through API and automatically gets all open issues, then creates a GitHub issue. First, our internal tool pulls out all Snyk security issues through the API and creates GitHub issues. We manually open a GitHub issue and give a command prompt to our AI agent. That prompt internally might work with Snyk autofix capability and gets the fixes correctly and creates a pull request. We review and check in the pull request, which is reviewed by experienced team members. This is the process we follow: create an issue based on a Snyk scan and for every issue, run a prompt so that it creates a pull request automatically with the fixes.
We do use Snyk documentation. We internally do not have many resources because we do not want to duplicate. Snyk guide is purely open and not logged in, so we use it.
Snyk documentation is extremely useful. Vulnerability-wise, I do not go to Snyk documentation frequently because in the current world, with my 25 plus years of experience, I used to fix many things manually before these tools existed. I need to know the intricacies of how to fix code. If you take 10 years back, there were tools and libraries which you could integrate with one or two lines, which solved the problem. With the current AI world, I do not even need that. If I get some issues, I do not even need to go to the Snyk website and read how to fix. I have an AI tool that can fix it if I ask it to. From an engineer's perspective, I still read the documentation. As a person who came from the manual world 25 years back, I still read the fix documentation. The documentation is very good, and being a general one, I understand the SAST world, so I did not find much problem with the documentation.
We are using Snyk, which is a SAST tool. There is a team in our organization who developed some AI agent on top of Snyk capabilities. I do not know exactly how they integrated Snyk, but our organization provides an AI agent which, if we run, automatically fixes issues and raises a pull request. In that case, we are indirectly using Snyk.
My overall rating for Snyk is 10 out of 10.
Extensive Vulnerability Detection and Seamless CI/CD Integration
Intuitive, Customizable, and Seamless Integration with Snyk
Accurate, Beginner-Friendly SAST Tool with CI/CD Integration
Another aspect I value is how quickly Snyk adapts to new CVEs. If a zero-day exploit appears, Snyk updates its CVE database within a maximum of 24 hours, helping to keep the code secure.