Snyk Runtime Sensor

My main use case for Snyk is to identify security vulnerabilities in application code and dependencies during the development lifecycle, before the code is deployed to production.

Once developers develop and push code to the repository, Snyk can scan the code and identify potential vulnerabilities early in the development process. Before implementing Snyk, we did not have a dedicated tool to identify vulnerabilities before deployment. This meant that some security issues could only be identified after the application was already deployed, where tools such as CrowdStrike could help detect security-related issues at the endpoint or runtime level.

With Snyk, we can shift security testing earlier in the Software Development Lifecycle (SDLC). Developers can identify and address vulnerabilities while they are developing and testing the application, rather than discovering them after deployment.

This is particularly important because we want to minimize the risk of security issues reaching production. Fixing vulnerabilities after deployment can potentially impact production environments and, ultimately, our customers. By integrating Snyk into our development and CI/CD process, we can identify vulnerabilities earlier, give developers an opportunity to remediate them before release, and improve the overall security and stability of our applications.

In summary, our primary goal is to shift security left by identifying and remediating vulnerabilities before code reaches production, reducing production risk and protecting our customers.

Snyk has had a significant positive impact on our organization by allowing us to identify and address security vulnerabilities earlier in the software development lifecycle. Before implementing Snyk, we did not have a dedicated tool to identify vulnerabilities in our code and dependencies before deployment.

After implementing Snyk, we were able to shift security testing to the development stage, allowing developers to identify and remediate vulnerabilities before the code reaches production. This has helped us reduce security risks, improve the overall quality of our code base, and avoid the additional time and effort involved in resolving vulnerabilities after deployment.

One of the most significant benefits has been the reduction in vulnerabilities across our services and dependencies. Previously, we were dealing with approximately 800–900 vulnerabilities across the dependencies used by our services. After implementing Snyk and following its recommendations, we have reduced these vulnerabilities by approximately 80–90%.

The remaining vulnerabilities are primarily associated with applications and code running on older infrastructure. We are actively working on migrating and modernizing these components, using Snyk's recommendations to identify the required remediation actions and prioritize improvements.

Overall, Snyk has helped us establish a more proactive security approach, reduce security-related incidents, improve code quality, and save development and operational time by addressing vulnerabilities before they reach production

These integrations are particularly valuable for our day-to-day development and security processes because they allow us to integrate vulnerability scanning directly into our existing development and CI/CD workflows. We can scan our code base and dependencies without requiring developers to use a completely separate process or tool. This makes security testing more seamless and helps us identify vulnerabilities before they reach production.

The ability to identify vulnerable dependencies is another feature I find very useful. Snyk not only identifies potential vulnerabilities but also provides recommendations that help developers understand the issue and determine the appropriate remediation approach. This makes it easier for our team to prioritize and resolve security issues.

From a usability perspective, I find Snyk straightforward and easy to work with. The dashboard provides clear visibility into vulnerabilities and helps us understand the overall security posture of our applications.

I also value Snyk's approach to security and data protection, particularly its focus on protecting customer data and maintaining appropriate security and privacy controls. This gives us additional confidence when using the platform as part of our development security process.

Regarding Snyk's AI capabilities, I find the results consistent and useful for supporting developers with security-related tasks. AI can help developers analyze issues and identify potential remediation approaches more efficiently, reducing the manual effort required. For us, this makes the overall vulnerability-management process faster and more effective while still allowing developers to review and validate the recommended actions.

Overall, the combination of CLI capabilities, CI/CD integrations, dependency analysis, ease of use, clear visibility, and AI-assisted security workflows makes Snyk a valuable tool for our development and security teams.

I think Snyk is already a strong and straightforward solution, particularly for organizations that want to identify vulnerabilities and dependency issues as early as possible in the development lifecycle. For small and mid-sized organizations, Snyk provides an effective way to introduce security scanning without making the development process overly complex.

The main area where I see an opportunity for improvement is pricing and licensing flexibility. While Snyk provides a strong set of features and I believe the functionality justifies the cost, more flexible pricing options could make the platform more accessible to smaller organizations and teams with limited security budgets.

For example, offering more flexible plans based on team size, usage, repositories, or scan volume could help smaller organizations adopt Snyk more easily and expand their usage as their environment grows.

Overall, I am satisfied with the product and its capabilities. My primary recommendation would be to make the pricing model more flexible while continuing to maintain the current level of security features and functionality.

I have been using Snyk for around one year.

Yes, based on our experience, Snyk has been stable and reliable in our environment.

Since deploying Snyk, we have been able to use it consistently across our development and CI/CD workflows, including our code repositories, Snyk CLI, Jenkins pipelines, and Docker/container environments. We have not experienced significant stability issues that have affected our development or deployment processes.

The scanning process is straightforward, and the integration with our existing development tools has worked reliably. This is important for us because security scanning needs to be part of the development lifecycle without becoming a bottleneck for developers or delaying deployments.

Another positive aspect is the consistent visibility Snyk provides into vulnerabilities and dependencies. We can continue monitoring the code base, identify newly introduced vulnerabilities, and track remediation without having to change our workflow significantly.

Overall, based on our experience, Snyk has been a stable and dependable part of our application security process, and we have been able to use it consistently as our security requirements have grown.

I would rate Snyk's scalability very highly. In our environment, Snyk has been easy to integrate into our existing development and CI/CD workflows, and it can scale as the number of repositories, developers, applications, and dependencies increases.

One of the biggest advantages is that Snyk can be integrated at multiple levels, including the developer's local environment, Snyk CLI, source-code repositories, Jenkins CI/CD pipelines, and Docker/container workflows. This allows us to maintain the same security approach as our development environment grows without requiring a completely different process for each application or team.

Snyk also provides centralized visibility into vulnerabilities and dependencies, which makes it easier for us to identify trends, prioritize risks, and track remediation across multiple projects. As we add more applications or repositories, we can continue applying the same vulnerability scanning and security practices.

For us, scalability is not only about handling more code. It is also about being able to scale security practices across the organization without significantly increasing operational complexity. Snyk has performed well in this area and fits our development environment as we continue to expand.

Overall, I would consider Snyk highly scalable for organizations that want to grow their application security program while keeping vulnerability management integrated with the existing development and CI/CD processes.

I would evaluate Snyk's customer service and technical support positively. In our experience, the support has been responsive and helpful when we have needed assistance with the platform, integrations, or technical questions.

The documentation and available technical resources are also useful for troubleshooting and understanding how to configure Snyk within our development and CI/CD environment. This makes it easier for our team to resolve common issues independently.

Since we are using Snyk under an Enterprise licensing model, having access to appropriate technical support is important to us. Overall, we have had a good experience with Snyk's support, and it provides the level of assistance we expect from an enterprise security platform.

No. We were not using any other dedicated solution for vulnerability scanning before implementing Snyk. We adopted Snyk as our first dedicated solution to identify vulnerabilities in code and dependencies during the development lifecycle.

The initial setup was straightforward and relatively easy. Snyk integrates well with our existing development and CI/CD environment, so we did not need to make significant changes to our infrastructure or development processes.

We were able to integrate Snyk with our code repositories, Jenkins, Snyk CLI, and Docker/container environment and start scanning our code and dependencies for vulnerabilities.

The setup process was easy to understand, and the dashboard provided good visibility into the identified vulnerabilities and dependencies. Once the integrations were configured, our developers could incorporate Snyk into their existing development workflow without significant disruption.

Overall, I would describe the initial implementation as simple, well documented, and easy to manage, particularly for an organization that already has an established CI/CD environment.

We are using Snyk under an Enterprise licensing model, which makes deployment and licensing management relatively straightforward for our organization. Since we have enterprise licensing, we do not have to manage separate licensing or deployment arrangements for individual users or environments.

We purchased Snyk directly from Snyk through an enterprise agreement, rather than through the AWS Marketplace or another third-party channel.

Overall, the setup and licensing experience has been straightforward, and the enterprise model provides the flexibility we need to integrate Snyk across our development and security workflows.

We evaluated different approaches and security solutions for identifying vulnerabilities in application code and dependencies, but Snyk stood out as the best fit for our requirements.

The main reason we selected Snyk was its ease of integration with our existing development and CI/CD environment, particularly with Jenkins, GitHub, Bitbucket, Docker, and the Snyk CLI. We wanted a solution that could be integrated into the development process without adding significant complexity for our developers.

Another key advantage was Snyk's ability to identify vulnerabilities in both the code and its dependencies at an early stage. The vulnerability information and remediation recommendations also made it easier for developers to understand and address the identified issues.

Some alternative approaches and tools can provide vulnerability scanning, but we found that they either required more effort to integrate into our existing workflow or did not provide the same combination of developer-focused security, dependency analysis, ease of use, and CI/CD integration that we were looking for.

Overall, Snyk provided the best balance of security coverage, ease of implementation, developer usability, and integration with our existing environment, which is why we selected it.

I would rate Snyk 10 out of 10 overall.

Snyk is a strong fit for our use case because of its integration with our development environment, code repositories, local development editors, Snyk CLI, and Docker workflows. The ability to identify vulnerabilities early in the development lifecycle, including vulnerabilities in dependencies and container images, has helped us improve our code base and reduce security risks before applications reach production.

Snyk is already deployed and actively used within our organization, and it has become an important part of our development and security process.

My advice to other organizations, particularly small and mid-sized organizations, is to consider Snyk if they want to improve their application security without making the development process overly complicated. Snyk can help teams identify vulnerabilities in their code and dependencies at an early stage, understand remediation requirements, and track vulnerability trends over time.

For organizations looking to improve code quality, reduce dependency-related risks, and build security into the development lifecycle, I would strongly recommend Snyk.

My main use case for Snyk involves finding and fixing security issues during application upgrades and migrations. In my work at ADP, I primarily use it to scan applications for vulnerabilities, identify risky dependencies, and help the team remediate issues before they become production problems. We had an initiative called Mythos where we had to upgrade the application and fix all security issues, and Snyk was very helpful during that time.

In one of the Mythos upgrades, Snyk highlighted a dependency vulnerability that was buried in the package chain, which was not something we would have caught quickly by manual review. Because it surfaced early, we fixed it during the upgrade itself instead of dealing with it later, which immensely reduced the risk and kept the rollout on track. That was one of the incidents that I had with Snyk, and it was absolutely very helpful during this complete Mythos upgrade for all the team members.

Another important part of how Snyk fits into my workflow is that it helps shift security left. Instead of waiting until the end of a project to discover vulnerabilities, we can catch them while we are still upgrading, migrating, or making any code changes. It also fits well into the developer workflow because it is just another plugin that we have in Visual Studio Code to be enabled to ensure all security issues are scanned and displayed visually. Once that is done, we can fix it in a matter of time, so having it as an extension in Visual Studio Code is one of the important things for developers because it becomes easily integrated into the workflow they are working with.

I find the most useful features of Snyk to be vulnerability scanning for code dependencies, containers, and infrastructure as code, with dependency intelligence that helps identify risky open-source packages and transitive issues. In major corporations like ADP, dependency intelligence is something that we actually care a lot about. I also like the fixed guidance feature, which includes upgrade suggestions and automated fixed pull requests. It has a developer-friendly workflow, so security issues show up where engineers already work, which is Visual Studio. We, as a team, appreciate two other important features: continuous monitoring, which helps us track risks even after the initial scan, and prioritization, allowing us to focus on the most important issues first.

Dependency ingestion helps us see not just the direct package with the issue but also the transitive dependencies underneath it, which matters a lot because many security problems hide in nested libraries. Without that visibility, we might just miss the real root cause. It also helps the team judge whether a vulnerability is actually relevant to our application or just something we can safely deprioritize, saving us a lot of time during upgrades and migration work. Regarding fixed guidance, it is so valuable because it turns the scan result into an action. Instead of just telling us something is vulnerable, it often points us towards a safer version, an upgrade path, or a remediation option that we can apply quickly. That makes the team faster because developers do not have to investigate every issue from scratch, reducing back and forth between development and security review.

Snyk had a very positive outcome on ADP and our workforce. The biggest positive outcome is less time spent on security remediation and fewer vulnerabilities carrying forward into later stages. Snyk's own metrics framework tracks open issues, new issues, resolved issues, PR checks, and time to fix, which maps well to the kind of benefits we saw in the Mythos initiative. The results included a 44% reduction in mean time to fix and a 62% reduction in critical vulnerabilities, along with an average of 2.2 development full-time employment worth of productivity gains. We saw a very positive impact mainly through time savings and earlier remediation as Snyk helped us catch vulnerabilities sooner during upgrades and migrations, reducing the effort for manual security issues. In practical terms, it improved a lot of developer productivity and helped the team fix security problems faster than ever with very little disruption.

Snyk could improve by reducing the alert noise because in large projects, security tools can surface a lot of findings. It helps when the platform is even better at highlighting what is truly urgent versus what can wait. Smarter prioritization would make it easier for developers to focus on the highest-risk issues first. Another area is workflow clarity during remediation. The fixed guidance is helpful, but it could be even better if the recommended path were more contextual, especially for complex dependency chains or upgrade conflicts. That would save a lot of time when teams are dealing with older applications and migration-heavy work.

I would also like to mention reporting and governance visibility. More flexible dashboards, clearer trend views, or easier ways to track remediation progress across teams would help it be stronger for leadership and security reviews. That kind of visibility matters the most when we are trying to show improvement over time. These are the points I have in mind that could be improved by Snyk.

I have been using Snyk for about eight months now, and it is absolutely valuable.

Snyk has been stable in our environment, and I have used it consistently during upgrades and security remediation work. It performs well without causing major disruption.

Snyk scales well for our needs. As the number of applications and upgrades grows, it continues to fit into our workflow without adding much overhead, remaining useful for ongoing vulnerability detection and remediation across the team. We dealt with plenty of applications as a team, and Snyk grew with us. It was not a bottleneck, so I would say its scalability is top-notch.

Customer support has been decent overall. When we needed help as a team, we approached them, and they are generally responsive and knowledgeable, though the experience can vary depending on the support level. The documentation is very strong, which reduces the need to go to support teams in most cases. I would rate the customer support as a 9 out of 10 because they are mostly knowledgeable, and Snyk definitely has very good documentation, leading to very little chance of needing to contact customer support.

Before Snyk, we used a mix of manual dependency checks, local static scans, and an older open-source scanner as our primary tooling, but we switched to Snyk because it had the coverage and accuracy. Snyk's vulnerability database and dependency intelligence catch more transitive and emerging issues than the older scanner we used. It also integrates easily into the developer workflow because we have an extension in VS Code that we could leverage, and it offers automated fixed PRs along with clear upgrade guidance, dramatically reducing the time spent on researching remediation steps compared with our previous approach. The enterprise readiness, continuous monitoring, and analytics were other aspects that helped us choose Snyk over other older tools.

We definitely saw a measurable return on investment after adopting Snyk for the Mythos initiative, with the biggest wins being time savings and faster remediation. On average, we reduced the mean time to fix security issues by roughly 40 to 50% for the classes of vulnerabilities Snyk surfaced, which shortened our exposure window and reduced rework during upgrades. For ad hoc dependency issues and transitive vulnerability remediation, we estimate developer effort per vulnerability dropped from 8 to 16 hours down to about 2 to 4 hours, thanks to Snyk's dependency intelligence and automated fixed PRs. Across the initiative, that translated into thousands of developer hours saved and the equivalent of one to three full-time developers of effort reallocated to feature work instead of bug or patchwork.

We also saw process benefits, with the number of critical, high-severity issues discovered late in testing or post-deployment dropping significantly. Roughly a 50 to 60% reduction for the targets we track, which reduced hotfix churn and decreased incident-related costs. Using Snyk in VS Code as an extension for CI pipelines meant many fixes were made pre-merge, and our PR blocking rate for high-risk vulnerabilities dropped, while the PR fix throughput increased. In terms of cost avoidance, faster fixes and fewer incidents reduced risk exposure and the potential remediation cost of production incidents. When combined with the time savings mentioned above, the team-level ROI is clear. The subscription cost is small compared to the developer hours recovered and reduced business risk during a major upgrade and migration program, so we saw a clear ROI, and it was very beneficial.

Pricing and setup were fairly straightforward overall because Snyk has a free tier, with paid plans starting around $25 per contributing developer per month, and enterprise pricing is custom, so the cost relates to the team size and the level of features needed. Since we use Snyk as a VS Code extension, the onboarding effort is low, and the licensing model is easy to understand because it scales by contributing developer. Overall, it felt manageable for the team and made sense for the value it provided.

Before choosing Snyk, we looked at a few alternatives, such as SonarQube and GitHub Advanced Security, which we were actually using previously. We switched to Snyk because we thought it would be easily integrated into our developer workflow. Snyk has very useful features and was particularly beneficial during the Mythos upgrade, leading us to switch to Snyk across the teams.

My advice would be straightforward: start with a clear use case and test Snyk in the workflow where your developers actually work. It is strongest when it is used early in the SDLC, especially for application upgrades, dependency checks, and fixing security issues before they reach production. I also suggest using it in a real project first, not just a demo, and paying attention to the dependency intelligence and fixed guidance because that is where it saves the most time. Evaluating Snyk on a real project and focusing on how well it fits into your daily development workflow is key. It is especially useful for catching vulnerabilities early, so the more closely you integrate it into your process, the more value you get. I would rate Snyk an 8 out of 10 overall.