Enso Application Security Posture Management

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.

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.

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.

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.

We have been using Snyk for more than a year.

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.

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.

Earlier, I used Checkmarx, which is another SAST tool. By default, any company and any SAST tool like Checkmarx or Snyk provides a plugin.

Snyk is integrated. I have not used it directly, though I may have used it indirectly.

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.

I typically use Snyk for checking the security and vulnerabilities in my repositories.

Recently, I have used Snyk in one of my repositories for security and vulnerability checks, providing comprehensive knowledge about the repository, including what it does and where the security vulnerabilities are located.

I am using Snyk for the first time and did not use any vulnerability scanning solution before this. I was previously doing Red Hat vulnerability scanning locally for dependency checks, which was not what I wanted.

Snyk's main features include open-source vulnerability scanning, code security, container security, infrastructure as code security, risk-based prioritization, development-first integration, continuous monitoring and alerting, automation, and remediation. The best features I appreciate are the vulnerability checking, vulnerability scanning, and code security capabilities, as Snyk scans all open-source dependencies for known vulnerabilities and helps with license compliance for open-source components.

Snyk integrates into IDEs, allowing issues to be caught as they appear in the code dynamically and prioritizes risk while providing remediation advice.

Snyk provides actionable remediation advice on where vulnerabilities can exist and where code security is compromised, automatically scanning everything and providing timely alerts.

Snyk has positively impacted my organization by improving the security posture across all software repositories, resulting in fewer critical vulnerabilities, more confidence in overall product security, and faster security compliance for project clients.

Snyk has helped reduce vulnerabilities significantly. Initially, the repository had 17 to 31 critical and high vulnerabilities, but Snyk has helped manage them down to just five vulnerabilities, which are now lower and not high or critical.

Although Snyk is strong, sometimes it flags vulnerabilities that are not reachable, not exploitable, and not relevant to a project. Better reachability analysis and context-aware scanning could improve this.

Snyk could benefit from a more optimized scanning engine and incremental scan caching.

I have been using Snyk for the previous one year.

I have no issues with Snyk's reliability; it is stable.

Snyk is very scalable and can handle my organization's growth and changing needs, allowing us to scale up to many stages and reduce developer costs, especially when we have fewer developers.

I never reached out to customer support because I never encountered any issues.

I considered SonarQube in detail before choosing Snyk.

My experience with pricing, setup cost, and licensing is good, as the overall setup experience is smooth with easy onboarding for connection with GitHub and GitLab. I primarily use it with GitHub, requiring just a few clicks to set up Snyk.

I can see that Snyk saves the costs of hiring security developers for vulnerability scanning and security checks, as that responsibility is now managed by Snyk.

Pricing is good for small teams, with a free tier or low-usage pricing available, and the licensing experience is straightforward but not very flexible.

My advice for others looking into using Snyk is that if you are starting a repository that is free from vulnerabilities and security checks, Snyk is a good option. It automatically provides advice on how to improve for reducing vulnerabilities and security issues, allowing for easy removal of vulnerabilities. You can use it for a free trial, and if it impacts your organization positively, you can consider further usage.

Snyk is a very good product for vulnerability code scanning and can be used effectively. I would rate this product a nine point five out of ten.

The most recent client had experience with other products that did not have some features Snyk provides, such as Fortify in the old version before OpenText acquisition. They gave feedback about the precision in discovering vulnerabilities. They found that Snyk can provide more insights about vulnerabilities than older applications in SAST and SCA.

We have integration with GitHub Actions to analyze the code and we use a double check in the pipeline. Our strategy is about shift left. The developers connect with Snyk, Git, and use this with the pipeline.

They evolved their maturity because they could find the vulnerabilities before the pipeline runs. They can find and correct these vulnerabilities in a step before the pushes and PRs to GitHub. They think it is a very positive feature.

I appreciate the UI. It is simple, fast, and I value the precision in the tests. The responses are positive.

Regarding the vulnerability database and AI, we have good experience with that. I cannot compare with other providers or vendors such as Veracode, Checkmarx, and others. All the tests are positive in my analysis.

Technically, we have better vulnerabilities detection in Checkmarx and Veracode. Both of them are more precise about vulnerabilities detection. Snyk is slightly less effective, but this is something they can improve on in the future.

We have been using the solution for one and a half years. Not much time.

We did not need support during the proof of concept.

The documentation is good. It is one of the reasons we did not need support. We could understand the implementation of the product and other features without the need for human interaction.

I made a proof of concept for a client with Checkmarx for about one month. I provided them a review about my experience. Now they are analyzing my results and considerations about other products too. I do not know if they already have a response about which product they will buy.

Snyk is less expensive.

It is simpler than other vendors. We have some difficulties with other license models. They are more complex and involve an acquisition of more products such as Synopsys and Checkmarx used a complex license model. Snyk has a license model simpler than most of the other vendors.

It was one of my three recommendations for my client. I am satisfied with the product. I rate Snyk 8.5 out of 10.