Snyk Runtime Sensor

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.