Snyk Reviews

Since some of our development is using open source packages, we need a way to identify the vulnerabilities before using those packages for development. Using Snyk, we can identify all the safe packages, which to use and which to not use, and create a safe repository for developers.

The goal is to catch the vulnerabilities early within the process and fix them before they get to the security review where they can cause deadlines to be pushed out to fix them.

We're using the cloud version.

It helps us meet compliance requirements, by identifying and fixing vulnerabilities, and to have a robust vulnerability management program. It basically helps keep our company secure, from the application security standpoint.

Snyk also helps improve our company by educating users on the security aspect of the software development cycle. They may have been unaware of all the potential security risks when using open source packages. During this process, they have become educated on what packages to use, the vulnerabilities behind them, and a more secure process for using them.

In addition, its container security feature allows developers to own security for the applications and the containers they run in the cloud. It gives more power to the developers.

Before using Snyk, we weren't identifying the problems. Now, we're seeing the actual problems. It has affected our security posture by identifying open source packages' vulnerabilities and licensing issues. It definitely helps us secure things and see a different facet of security.

It also allows our developers to spend less time securing applications, increasing their productivity. I would estimate the increase in their productivity at 10 to 15 percent, due to Snyk's integration. The scanning is automated through the use of APIs. It's not a manual process. It automates everything and spits out the results. The developers just run a few commands to remediate the vulnerabilities.

• The wide range of programming languages it covers, including Python
• Identifying the vulnerabilities and providing information on how to fix them — remediation steps

It's very easy for developers to use. Onboarding was an easy process for all of the developers within the company. After a quick, half-an-hour to an hour session, they were fully using it on their own. It's very straightforward. Usability is definitely a 10 out of 10. Our developers are using the dashboard and command lines. All the documentation is provided and I've never had an issue.

We have integrated Snyk into our software development environment. It's something that is ongoing at the moment. Our SDE is VS Code.

Another important feature is the solution’s vulnerability database, in terms of comprehensiveness and accuracy. It's top-notch. It pulls all the data from the CVE database, the national vulnerability database. It's accurate and frequently updated.

We use the solution's container security feature. A lot of the vulnerabilities can't be addressed due to OS restraints. They just can't be fixed, even with their recommendations. I would like to see them improve on this.

A feature we would like to see is the ability to archive and store historical data, without actually deleting it. It's a problem because it throws my numbers off. When I'm looking at the dashboard's current vulnerabilities, it's not accurate.

We have been using Snyk for a little more than a year.

The stability is very good. I haven't noticed any downtime.

It provides easy deployment for different code repositories, so it's easily scalable.

We have about 20 to 25 users and it's being used very extensively, across all our applications.

Their technical support is top-notch, a 10 out of 10. I have a Slack channel for direct discussions with support. And I have my account manager for any questions or issues I run into. Response time ranges between instant and three hours. If they don't know the question or the issue, they'll escalate. They'll have someone else join the Slack or give me a Zoom session.

This is the first of its kind, that we are using.

The initial setup was very straightforward. The integrations with our code repositories, like Bitbucket and GitHub, are direct. You enter their required information and just pull data from them. There was no setup for any additional VMs or anything else.

Developer adoption has been pretty positive, since it's easy to use. We have 100 percent adoption. They understand the need for security with software development. Everyone's happy with the product, and it allows them to catch vulnerabilities earlier in the software development cycle, rather than later, so they can fix them before they get to the security-review process.

The deployment took a few hours, maybe even less. I was the only one involved in the process. I just followed the directions. We just planned on identifying the specific repositories linking to Snyk, and then started scanning specific projects.

I also take care of maintenance of the solution and it takes less than 5 percent of my time. There is very little maintenance needed since it's a SaaS product.

We have seen ROI, although I don't have any data points on it. It's very valuable. It saves time for the developers and security team by quickly identifying things and fixing them before they get down the pipeline. It prevents the creation of additional roadblocks and complexity and the pushing out of deadlines to address issues once they are too far down the pipeline.

We didn't find any other options on the market.

The biggest lesson I've learned from using this solution is the complexity of open source licenses. I wasn't aware of all the different types of licenses, and all the terms and conditions required to use specific open source packages.

Our use case is basically what Snyk sells itself as, which is for becoming aware of and then managing any vulnerabilities in third-party, open-source software that we pull into our product. We have a lot of dependencies across both the tools and the product services that we build, and Snyk allows us to be alerted to any vulnerabilities in those open-source libraries, to prioritize them, and then manage things.

We also use it to manage and get visibility into any vulnerabilities in our Docker containers and Kubernetes deployments. We have very good visibility of things that aren't ours that might be at risk and put our services at risk.

Snyk's service is cloud-based and we talk to that from our infrastructure in the cloud as well.

We are a business that sells services to other businesses. One of the things that we have to sell is trust. As a small company, we've had to go quite a long way to mature our development and security processes. We've been ISO 27001-certified for a while and we got that very early, compared to the life cycle of most businesses. But that's because when we're talking contracts with customers, when we're talking information security reviews with customers, it's really powerful to be able to say, "We have Snyk, we use it in this way." A lot of the questions just go away because people understand that that means we've got a powerful and comprehensive tool.

Certainly, from a finding-of-vulnerabilities perspective, it's extremely good. Our problem is scale. We have something like 7,000 dependencies in our code and we could go and check those ourselves, but that would be a huge waste of time. Snyk's ability to scan all of those every time we build, and keep a running status of them and recheck them daily, is extremely valuable for making us aware of what's going on. We've wired Snyk up into Slack and other things so that we get notifications of status, and that's useful.

It has reduced the amount of time it takes to find problems by orders of magnitude because it's scanning everything. Without the tool it would be horrific; we just couldn't do it. It takes seconds for a scan to run on each of our libraries and so that's an amazing performance improvement. Compared to having nothing, it's amazing.

In terms of developer productivity, because of the way that our development community works, they're pulling in third-party libraries. So they worry less about the choice of the third-party library, but it could inform them that there's a risk, and then they then have to take action. We probably spend more time securing our product, but get a more secure product, which is actually what we want.

Overall, knowing what the risks are, and being able to make considered judgments about those risks, means that we are much more comfortable that our product is secure. And when there are high-risk issues, we're able to take action very quickly. The time to resolution for anything serious that is discovered in downstream libraries is dramatically reduced, and that's really useful.

The core offering of reporting across multiple projects and being able to build that into our build-pipelines, so that we know very early on if we've got any issues with dependencies, is really useful.

We're loving some of the Kubernetes integration as well. That's really quite cool. It's still in the early days of our use of it, but it looks really exciting. In the Kubernetes world, it's very good at reporting on the areas around the configuration of your platform, rather than the things that you've pulled in. There's some good advice there that allows you to prioritize whether something is important or just worrying. That's very helpful.

In terms of actionable items, we've found that when you're taking a container that has been built from a standard operating system, it tends to be riddled with vulnerabilities. It's more akin to trying to persuade you to go for something simpler, whether that's a scratch or an Alpine container, which has less in it. It's more a nudge philosophy, rather than a specific, actionable item.

We have integrated Snyk into our software development environment. The way Snyk works is that, as you build the software in your pipelines, you can have a Snyk test run at that point, and it will tell you if there are newly-discovered vulnerabilities or if you've introduced vulnerabilities into your software. And you can have it block builds if you want it to. Our integrations were mostly a language-based decision. We have Snyk integrated with Python, JavaScript Node, and TouchScript code, among others, as well as Kubernetes. It's very powerful and gives us very good coverage on all of those languages. That's very positive indeed.

We've got 320-something projects — those are the different packages that use Snyk. It could generate 1,000 or 2,000 vulnerabilities, or possibly even more than that, most of which we can't do anything about, and most of which aren't in areas that are particularly sensitive to us. One of our focuses in using Snyk — and we've done this recently with some of the new services that they have offered — is to partition things. We have product code and we have support tools and test tools. By focusing on the product code as the most important, that allows us to scope down and look at the rest of the information less frequently, because it's less important, less vulnerable.

From a fixing-of-vulnerabilities perspective, often Snyk will recommend just upgrading a library version, and that's clearly very easy. Some of the patching tools are a little more complicated to use. We're a little bit more sensitive about letting SaaS tools poke around in our code base. We want a little bit more sensitivity there, but it works. It's really good to be able to focus our attention in the right way. That's the key thing.

Where something is fixable, it's really easy. The reduction in the amount of time it takes to fix something is in orders of magnitude. Where there isn't a patch already available, then it doesn't make a huge amount of difference because it's just alerting us to something. So where it wins, it's hugely dramatic. And where it doesn't allow us to take action easily, then to a certain extent, it's just telling you that there are "burglaries" in your area. What do you do then? Do you lock the windows or make sure the doors are locked? It doesn't make a huge difference there.

One of the things that I have mentioned in passing is because we have a security team and we have the development team. One of the things that would make the most difference to me is because those two teams work independently of each other. At the moment, if a developer ignores a problem, there's no way that our security team can easily review what has been ignored and make their own determination as to whether that's the right thing to do or not. That dual security team process is something that I'd love to see.

Other than that, there is always more work to do around managing the volume of information when you've got thousands of vulnerabilities. Trying to get those down to zero is virtually impossible, either through ignoring them all or through fixing them. That filtering or information management is always going to be something that can be improved.

We've been using Snyk for about 18 months.

The stability is pretty good.

We've had two challenges over the two years we've been using Snyk. One was the size of our projects in our JavaScript world. It meant that some of the tests would fail through memory issues. They've done a lot of work on improving that, and we have found some workarounds. 

Sometimes, because we're talking out to Snyk services, our pipelines fail because the Snyk end isn't running successfully. That doesn't happen very often, so it hasn't been a major impact, but there have been one or two cases where things didn't work there.

The solution is scalable, absolutely. We plan to increase our usage of Snyk. As we grow, every developer will be put into it. Everything we build, all of our development, is using Snyk as the security scanning tool.

Snyk's technical support is very good. We haven't used it much. I've engaged with customer success and some of the product managers and they're really keen to get feedback on things. 

We have had one or two things where we have talked to support and they have been very positive engagements.

We were small enough that we didn't have a previous solution.

The deployment was easy. When we were first evaluating Snyk, our automation engineer got a test account, installed it, and built it into our development pipelines without needing any support at all from Snyk. It was one of the more interesting sales engagements. They sent us an email, but we got it up and going and were using it in its trial mode without needing any assistance at all. That's clearly a demonstration of that ease of integration.

Working end-to-end, it took a couple of days for one person to get it wired up.

We followed the Snyk recommendations. We built a container that takes the Snyk service, and we run that in our build-pipeline. It dropped in very easily because of the way we were already operating.

In terms of developer adoption, we had to mandate it. So everybody uses it. It's built into all the pipelines. Generally, it's pretty good. The engineering team has 17 people and pretty much everybody is using Snyk as part of that. I don't think security is necessarily at the forefront of everybody's minds, and we're working on that. Snyk has helped.

We have a very complex infrastructure so the only challenge with Snyk is that it tells us a lot of information. They're pretty good at managing that, but you still have to take action. It's very good for knowing things, but it's also pretty good at being able to work out how to focus your attention.

That volume of information, where you get lots of things that are not important or not critical, tends to create a little bit of "blindness" to things. We're used to Snyk tests failing, alerting us to things that we're choosing to ignore at that moment because they're not fixable. That's one of the interesting challenges, to turn it into actionable information.

We had a lot of information security audits and we found that Snyk enabled sales because they weren't being blocked by InfoSec issues. That means that it probably paid for itself with the first customer deal that we were able to sign. We were able to show them that we had Snyk up and working really quickly, which was great. 

In terms of other metrics, it's slightly harder to measure, because it's allowing us to prevent problems before they become issues. But from a commercial engagement point of view, it was well worth it, very quickly.

It's good value. That's the primary thing. It's not cheap-cheap, but it's good value. We managed to build a package of features that we were able to live with, in negotiation, and that worked really well. We did a mix and match. We got single sign-on and some of the other things.

The Kubernetes, the container service, versus the source-code service, for us, as a cloud deployment, was well worth it. The ability there has been really useful, but that's clearly an extra cost.

There are other tools that can perform some of the functions Snyk does. We did some analysis of competitors, including Black Duck Synopsys and Veracode, but Snyk was clearly the most hungry and keen to assist, as a business. There were a lot of incumbent competitors who didn't really want our business. It felt like Snyk clearly did want to do the right thing and are continuing to improve and mature their product really fast, which is brilliant.

Snyk, was at a good price, has very comprehensive coverage, and as a company they were much easier to engage with. It felt like some of the other competitors were very "big boys." With Snyk we had the software working before we'd even talked to a sales guy, whereas with other solutions, we weren't even allowed to see the software running in a video call or a screen-sharing session until we'd had the sales call. It was completely ridiculous.

My advice is just try it. If you've got a modern development pipeline, it's really easy to wire up, if you've got somebody with the right skills to do that. We found with a development community, it's really easy to build these things. Get on with it and try it. It's really easy to trial and see what it's telling you about. That's one of the great upsides of that model: Play with it, convince yourself it's worth it, and then talk to them about buying it.

It's hard to judge Snyk's vulnerability database in terms of comprehensiveness and accuracy. It clearly is telling us a lot of information. I have no reason to doubt that it is very good, but I can't categorically back that up with my own empirical evidence. But I trust them.

I don't get the sense there are many false positives from Snyk, and that's a very positive thing. When it tells us something, it's almost certainly a real issue, or at least that a real issue has been found somewhere in the open-source world. 

What is always harder to manage is to know what to do if there is no resolution. If somebody has found a problem, but there is no fix, then we have a much more interesting challenge around evaluation of whether we should do something. Do we remove that library? Do we try and fix it ourselves, or do we just wait? That process is the more complicated one. It's less of a false positive issue and more an issue of a real finding that you can't do anything about easily. That can sometimes leave you ignoring things simply because there's no easy action to take, and that can be slightly dangerous.

The solution allows our developers to own security for the applications and the containers they run in the cloud, although that's still something we're working on. It's always a challenge to get security to be something that is owned by developers. The DevOps world puts a lot of responsibility on developers and we're still working to help them know; to have better processes and understand what they need to be doing. We still have a security oversight function who is trying to keep an eye on things. We're still maturing ourselves, as a team, into DevSecOps.

As for Snyk's lack of SAST and DAST, that's just another one of the tools in the toolkit. We do a lot of our own security scanning for application-level or platform-level attacks. We have pen tests. So the static application is not something that we've seen as particularly important, at this point.

Snyk is an eight out of 10. It's not perfect. There are little things that could clearly be improved. They're working on it as a company. They're really engaged. But the base offering is really good. We could also use it better than we are at the moment, but it's well worth it. It's brilliant.

The biggest lesson I have learned from using this solution is that there is a big gap between thinking your software is safe and knowing what the risks are. Information is power. You don't have to take action, but at least you are informed and can make a considered judgment if you take it seriously. That is what Snyk really provides.

The ethos of Snyk as a company is really positive. They're keen to engage with customers and do something in a slightly different way, and that younger, hungrier, more engaged supplier is really nice to work with. They're very positive, which is good.

The primary use case is dependency vulnerability scanning and alerting.

We have integrated it into our software development environment. We have it in a couple different spots. Developers can use it at the point when they are developing. They can test it on their local machine. If the setup that they have is producing alerts or if they need to upgrade or patch, then at the testing phase when a product is being built for automated testing integrates with Snyk at that point and also produces some checks.

The integration of SDE has been easy. We have it on GitHub, then we are using an open source solution that isn't natively supported, but Snyk provides ways for us to integrate it with them regardless of that. GitHub is very easy. You can do that through the UI and with some commands in the terminal. 

The sooner that we can find potential vulnerabilities, the better. Snyk allows us to find these potential vulnerabilities in the development and testing phases. We want to pursue things to the left of our software development cycle, and I think Snyk helps us do that.

A lot of the containerization is managed by some of our shared services teams. The solution’s container security feature allows those teams to own security for the applications and containers they run in in the cloud. Our development operations is a smooth process. We are able to address these findings later in the development process, then have the scans at the time of deployment. We are then able to avoid time crunches because it allows us to find vulnerabilities earlier and have the time to address them.

It provides better security because we make sure that our libraries dependencies and product stay up-to-date and have the most current code available. Yet, we are able to quickly know when something requires urgent attention.

It raises alerts on vulnerable libraries and findings. It scores those alerts and allows us to prioritize them.

It is very easy to use: The UI is very polished and the API is straightforward. Our developers seldom have a thought like, "This is very odd how they are doing this." The solution seems very intuitive.

I am impressed with Snyk's vulnerability database in terms of its comprehensiveness and accuracy. There have been times when I know that brand new vulnerabilities have come out, then it's only taken them a day or two to adopt them and get them processed into their database. I feel pretty confident in the database.

The security container feature is good and straightforward. The solution’s actionable advice about container vulnerabilities is a little more straightforward, because in most cases, you need to upgrade. There is not as much investigation that needs to go into that. So, the decision to upgrade and fix those is straightforward.

Their API and UI are great.

If they were able to have some kind of SAS static code analysis that integrates with their vulnerability dependency alerting. I think that would work really well. Because a lot of times, only if you have this configuration or if you are using these functions, your code will be vulnerable. The alerts do require some investigation and Snyk could improve the accuracy of their alerting if they were to integrate with the SAS static code analysis.

I would like to give further ability to grouping code repositories, in such a way that you could group them by the teams that own them, then produce alerting to those teams. The way that we are seeing it right now, the alerting only goes to a couple of places. I wish we could configure the code to go to different places.

Close to three years.

My impressions of the stability are very high.

We don't require staff for deployment and maintenance of this solution.

It is pretty scalable. We had a few projects that are too large, but they have actually produced fixes which help with that. As of right now, I feel that they are very scalable.

Developer adoption is 90 percent. Our goal is 100 percent. We are currently doing roadmap work, but we will be at 100 percent soon.

Our users are primarily developers. We have the 100 seat license, and I think we have around 80 to 90 users.

Snyk's technical support is big. I have worked with them several times. They are responsive and have always been able to help me with whatever things I am trying to do.

The initial setup is straightforward. They have great documentation, which is relatively straightforward. There are a couple different options on how you can integrate it. This allows you to sort of pick the easiest way. It was simple for most of our use cases and the ways that we needed to integrate with it.

Our initial deployment took less than a week.

We talked to a solutions architect for an hour. That was basically it. Our experience with them was good. Everything seemed very straightforward, so it all went smoothly.

We have seen ROI. The product is more secure. Snyk has allowed our developers to spend less time securing applications, increasing their productivity. This goes back to being able to identify things earlier within the development cycle and having the time, not having to handle all these things in a panicked, chaotic manner, in order to fix something.

Snyk has reduced the amount of time it takes to find problems. By finding problems early on in the development cycle, the solution is probably saving us about a month.

The solution has reduced the amount of time it takes to fix problems. Their database has a great description because it's easy to figure out what the problem is, then we can figure out what needs to be fixed. The time that it saves us is relatively small, about a day.

Make sure you know how you want to structure the product at the time that deploy it, because it's hard to go back and restructure it. Prepare a deployment plan before you implement it.

Snyk reports vulnerabilities and alerts on vulnerable libraries, but there are usually a lot of stipulations on if it will be a vulnerability within the code. For example, it might say, "This library is vulnerable, but only if you're using these functions." Then, there is kind of a decision: 

• Is it just going to be easiest to upgrade it and not really investigate it? 
• Or do you investigate it and figured out if it's a false positive or not? 

So, it depends on how you define false positive. It alerts on vulnerable libraries, but it also says, "Only if you're doing this with these functions," which a lot of the times the case is not, but requires some investigation.

Snyk supports 95 percent of the environment that we have. We do have some code that is not supported by them.

We have other solutions to cover SAST and DAST. If Snyk were to come out with these solutions, we would be interested in what they have and possibly adopting those. It's not a concern for us that they don't have those, because we use other solutions to cover SAST and DAST, but we also want to be able to cover vulnerable dependency alerting.

They're always coming out with new stuff.

I would rate the solution as a nine out of 10.

Talking about the current situation in our security posture, we decided to choose a platform which could help us to improve our Security Development Lifecycle process. We needed a product that could help us mitigate some risks related to the security side of open source frameworks, libraries, licenses, and IT configuration. We were interested in a solution that could also utilize Docker images that we are using for the deployment. In general, we were interested in a vulnerability scanner platform for performance scans to deliver and calculate our risks related to code development.

We have integrated it with our infrastructure, collecting images from there, and performing regular scans. We also integrated it with our back-end in version control systems.

Sometime ago, we deployed a new product based on web technologies. It was a new app for us. From the beginning, we integrated Snyk's code scannings that the product is based on. Before the production deployment, we checked the code base of Snyk, and this saved us from the deployment with the image of the solution where there were some spots of high severity. This saved us from high, critical vulnerabilities which could be exploited in the future, saving us from some risks.

It helps find issues quickly because:

1. All the code changes go through the pipeline.
2. All new changes will be scanned. 
3. All the results will be delivered. 

This is about the integration. However, if we're talking about local development, developers can easily run Snyk without any difficulties and get results very quickly. 

It is one of the most accurate databases on the market, based on multiple open source databases. It has some good correlation and verifications about findings from the Internet. We are very happy on this front.

The solution’s container security feature allows developers to own security for the applications and containers they run in in the cloud. They can mitigate the vulnerabilities in the beginning of the solution's development. We can correlate the vulnerabilities in our base images and fix the base image, which can influence multiple services that we provide.

We see that they are continuously working on the Kubernetes security and platform security checking. This is interesting for us, because we are an enterprise customer, and all of these features are made available for us.

It has an accurate database of vulnerabilities with a low amount of false positives.

The container security feature provides good actionable advice for points of integration. 

The documentation sometimes is not relevant. It does not cover the latest updates, scanning, and configurations. The documentation for some things is wrong and does not cover some configuration scannings for the multiple project settings. For example, sometimes the code base condition is consistent on multiple modules. It's kept on different frameworks and packet managers. This requires Snyk to configure it with a custom configuration from the scan. From this point of view, the documentation is unclear. We will sometimes open enterprise tickets for them to update it and provide us specific things for the deployment and scanning.

There is no feature that scans, duplicates it findings, and puts everything into one thing.

The communication could sometimes be better. During the PoC and onboarding processes, we received different suggestions versus what is documented on the official site. For example, we are using Bitbucket as a GitHub system for our code, especially for Snyk configurations. The official web page provides the way to do this plugin configuration. However, if we talk about doing direct connection with our managers from Snyk, they suggested another way.

We have been using this product for five months.

The product is sometimes unstable.

There aren't any limitations because we are using it as a SaaS platform. As an enterprise customer, we can create teams and additional projects as well as involve additional people. These things can easily be covered for our entire business.

We currently have 20 developers who use it.

We are planning to increase usage based on the things that Snyk can provide us, like Kubernetes security. I would rate our adoption rate at a seven out of 10.

Our enterprise success manager from Snyk has open discussions with us. We have been with Snyk at meetings and webinars with our engineers. Documentation for scanning on the developer side is clear and good. We don't have any concerns from our development team that it is difficult or unclear. Everything is good on this point.

It has poor support sometimes for the Scala language when running scans of the official Docker images from Snyk. Scala is a part of the Java framework. We need to customize it and built our own Snyk images. The platform provide the images, but the execution is too long.

Their customer success management is an eight out of 10, because every enterprise ticket should go to general support initially.

I would rate the first line of support as a six out of 10, but their technical site engineers who help us are an eight out of 10.

We did not previously use another solution in this company.

The initial setup was not complex; it was easy for us. I thought the configuration guidelines offer a clear way for integration with registries, where we are hosting our Docker images. It was easy to integrate with Docker platforms for the SoC configuration, which was done in one working day. This was very fast. 

The documentation of installation (for the scanner on endpoints for development) was clear. We quickly checked all our inbox code. All of the processes of enrollment were clear and fast.

The initial setup took one month. Our deployment is still going on.

Its enterprise support is a very good feature. This helped us to enforce processes faster. 

Our implementation strategy is based on suggestions from the product managers and success managers from Snyk. In general, we are going to collect all of the vulnerabilities and findings as soon as possible to aggregate the results and mitigate the false positives. This is to correlate the results of a licensed check-in and create our own policies for future detections.

For part of the configurations, we needed help from Snyk because sometimes the documentation is wrong. It can also be unstable, so we cannot integrate the scannings with an unknown error. In these cases, we conduct our enterprise support to help out. It does requires us to contact support regularly.

It will probably be a year before we see value from the Snyk platform.

Snyk has reduced the amount of time it takes to find problems by 30 to 40 percent.

The price is good. Snyk had a good price compared to the competition, who had higher pricing than them. Also, their licensing and billing are clear.

We have multiple language service platforms based on different language scopes. We were interested in a platform which could cover all of the languages that we are using. We are a mobile-first application, so we were interested in the iOS and Android code and having back-end services that could be deployed via different languages. Another aspect was checking Docker images for vulnerabilities, using Gartner investigation and market research, and applying my personal experience in this niche (Security Development Lifecycle).

We had a comparison between several vendors, like Aqua Security, Snyk, and Qualys. In general, Snyk was the only solution that had a Docker scan aspect to it. It also offered us open scan for vulnerabilities. For this reason, we chose Snyk. It covers not only continuous scanning, but also provides the license scanning and open source scanning from the box. While there are lot of open source products on the market who offers this capability, Snyk aggregates all these features in one place.

If I had to go through the process of choosing a platform for our company again, I would chose Snyk. 

Check the following before using Snyk:

• Your language frameworks and whether Snyk can cover them.
• The specific packet managers that your are using.
• How Snyk performs with all your platforms, not just the main part. Gauge the difficulty. 

Check the solution for all your language specifics. We have had some interesting projects where the default configuration does not work. Before using such products, you should check it in the most complex projects that you have.

Based on all our products, including Snyk, we have seen a 50 percent reduction in the amount of time it takes to fix problems. 

The solution allows our developers to spend less time securing applications, increasing their productivity. 

The feedback: It's a very interesting solution. It is clear what we are using it for and how we should use it. However, if we are talking about the interest from our developers, then the solution was evaluated as a medium. This is because of its readiness for implementation and adoption process.

I would rate this solution as an eight or nine out of 10.

We use it as a pretty wide ranging tool to scan vulnerabilities, from our Docker images to Ruby, JavaScript, iOS, Android, and eventually even Kubernetes. We use those findings with the various integrations to integrate with our teams' workflows to better remediate the discoveries from Snyk.

It gives us a uniform way to access the vulnerability information across a wide range of projects, teams, and structures. Once there were teams in Snyk, I was able to move people around if they wanted to see other projects or had questions about how other teams were doing things. Instead of having to tell a team, "Oh, you're using this language so you have to use this tool," or, "You're using this language so you have to do it this way or that way," all the reports are uniform, which makes viewing everything a lot easier than piecing things together.

Snyk reduces the amount of time it takes our guys to find problems. It's tough to estimate how much it has reduced the time because we didn't really have a process before to aggregate as much information on as wide a range of projects as we do now. We don't really have a great basis for comparison. But judging from the fact that we didn't do any of this before and teams were pretty blind about the health of their dependencies and versions, this has not only been a time saver, but the biggest win is enlightenment and ease of use to actually be able to get this information in the first place.

As far as the amount of time it takes to triage vulnerabilities and go through the upgrade process, it's definitely more streamlined, overall.

An example of the way it has affected the overall security of our applications is from during one of the first weeks that we rolled it out with one of our projects. We went from 15 vulnerabilities in it to four or five, and those four or five were un-upgradable and we were not affected by them. That means we were able to knock out any vulnerabilities in that project right away, which was a few quick wins for us, compared to who knows how long all of those had been in the project. We hadn't really known that until we turned Snyk onto the project and then we solved those within a week.

The most valuable features are their GitLab and JIRA integrations.

The GitLab integration lets us pull projects in pretty easily, so that it's pretty minimal for developers to get it set up. 

Using the JIRA integration, it's also pretty easy to get the information that is generated, as a result of that GitLab integration, back to our teams in a non-intrusive way and in a workflow that we are already using. Snyk is something of a bridge that we use; we get our projects into it and then get the information out of it. Those two integrations are crucial for us to be able to do that pretty simply.

The ease of use for developers, on a scale of one to 10, is about an eight. The main feature of the reporting on the vulnerabilities and the information that you get from that are really easy to go through and use and interact with, whether it's pushing it to JIRA or ignoring certain vulnerabilities if you're not at risk. There are a couple of parts that, once you get into the settings a little bit more, are a little confusing and tricky. That's why it's not a nine or a 10, but the main features are pretty well done and easy to use.

The solution's ability to help developers find and fix vulnerabilities is pretty fast. The scanning for all of our various code bases could probably be done in under five minutes. It gives pretty clear information to developers, right away, about what we are vulnerable to and what we will be vulnerable to. Even if a fix or a patch is not out yet for a certain vulnerability, it will still give us that information. It also tells us what versioning, specifically, we need to upgrade to, which helps us determine the best upgrade path for ourselves, because sometimes our projects that are a little bit restricted as far as versioning goes.

Because Snyk has so many integrations and so many things it can do, it's hard to really understand all of them and to get that information to each team that needs it. Since I was the one who originally set up Snyk, I have been in charge of evangelizing all the features of it, but that's almost a full-time job, and that's not my entire job. I haven't been able to get all of that information out quite as well as it could be. If there were more self-service, perhaps tutorials or overviews for new teams or developers, so that they could click through and see things themselves, that would help.

There is so much in there already that it's easy to get a little bit lost, but thankfully they also have great documentation on pretty much all of the features and plugins, to understand them. So it can be up to the person, depending on how much of a self-starter they are, to see an integration and then go poke around and figure out how to get things working.

I have been using Snyk for about a year.

In terms of downtime there have been some road bumps with version upgrades and things, but otherwise it's pretty much a self-running service, and the day-to-day maintenance is pretty low.

The solution itself is really well done. We know that being on-prem is a little bit tougher because the roll-out cycle is a little slower. They're actively investigating ways around that, including having us beta their AWS Snyk on our AWS account. That would remedy our upgrade issues, where the upgrades are only happening about once a month, versus their SaaS offering, which has continuous updates.

Once we've upgraded, we've been fine, but the upgrade path itself has been a little bumpy. But they've got solutions that they're working on to meet customers halfway between that on-prem solution and the SaaS offering, which is definitely something that is nice to see. It's also good to see that they're working on what they know are some of the pain points in their product.

We haven't had any issues as far as scalability goes. That hasn't even actually crossed my mind, as far as worrying about any sort of limits that we might have. Maybe we'll get there one day, but at the moment that's something that seems somewhat far off. Understanding the way they built the product too, especially the on-prem, we would probably be able to scale things if we really needed to.

At the moment we have about 50 users in the tool itself, users who go in and look at results. But we have about another 100 or 150 who have their code actually scanned by Snyk, whether they know it or not, through our main application. Some of the GitLab applications have developers on the projects, but it could be that only their leads are in the Snyk tool at the moment.

Out of our total number of teams, about 60 to 70 percent are in Snyk at the moment. As time allows, and as the projects come up and the need arises, we plan to roll it out. There are some teams that don't have projects that would fall under Snyk's abilities at the moment, but there are still a couple of other teams that could definitely be added.

They've been willing to help at every step of the way. I've been able to work directly with the engineers who actually built the tool. It's not like I'm going through some customer support team first and then having to open a case and raise it up through levels of support. I have a clear channel to the developers who built these plugins and integrations and who know how they work. They also have other tools that they've created on the side, tools that they see a lot of customers creating themselves. It's been helpful to get that extra help across the board, for whatever needs we have.

We didn't have a direct previous solution. We did have a SAST tool that we had been using a lot across our main repositories. But we didn't have anything that would cover a lot of the other teams' languages and dependencies. This is the first big tool that we've introduced for scanning.

We went with Snyk because of the wide range of integrations and ease of use. Those were a couple of the big points, and the fact that they offered an on-prem solution.

Because we were doing the on-prem version, it was a little bit more complex than it could have been. I was also a little bit new to some of the technologies that were used to set it up, so I was learning as I went.

When we initially got it up and running, it took another developer about a week to do that, maybe less. Once he trialed things and we signed our contract, he turned it over to me and that took a day and a half.

Our initial goal, once we got Snyk up and running, was to get it scanning our main repository, but not to block developers on vulnerabilities that were found. We came up with a solution that only dependencies that the developer had changed or touched in their commit would be scanned. That allowed us to focus in on having each developer own their changes, instead of blocking everyone due to any sort of vulnerability that came up in the project. Those were our immediate goals, and since then we've been expanding on things.

As for developer adoption, we've been spreading it out to more and more teams. As each team has gotten familiar with it, they've gotten around to other teams by word of mouth, using certain features. Right now, we have six different teams, and each team has anywhere from one to four projects in Snyk. We've been seeing pretty steady growth too. As new projects come up they're put in there right away so that developers know, right off the bat, if they have any issues or vulnerabilities in those projects.

The biggest point of friction was when we initially announced that we were going to block developers on vulnerable dependencies. The understanding was that we were going to block everyone on any sort of dependency change that had a vulnerability. But our very narrow focus on each developer's changes, specifically, allowed us to scope that down to the single developer that would be responsible for those upgrades, so that we wouldn't introduce new vulnerabilities in the first place. That was the biggest point of concern but we were able to remedy it and had a good story for it right away.

Since then, people have come to me and said, "How can I get this into Snyk?" and we've been able to work with the various teams. People have gone from fearing a tool of this nature to being able to use it to strengthen the security posture of their projects.

Snyk helped us set it up, especially initially, and along the way too, as we've had questions.

Regarding time to value of the solution in our company, in our case we had to set up a couple of IP table rules that would allow Snyk to talk to the other infrastructure that we needed it to talk to. Once we had those things cleared up, getting the full use out of Snyk was super-quick, when it came to getting a project in there, scanning it, and getting the results back into something like JIRA for developers to more easily use going forward, and for monitoring their projects.

We used a couple of other tools, especially initially, to assess what we were going to go with. It seems that Snyk has not been deficient in any way in terms of the comprehensiveness and accuracy of the vulnerability database. It supports a wide range of languages as well. There's always information, it seems, on whatever language you would like, and our main ones are well supported. I don't feel that we're missing any vulnerability information there. I've never once thought, "Oh, I should go double-check this because Snyk might not have it." I haven't come across that situation.

Focus initially on setting up a clear path for developers to integrate with the tool. Initially, most developers are not super excited about security tools and scanning in the first place; very few people are. So working on the developer adoption, and showing them what features are available and how that can directly benefit their projects, without their feeling like they have a lot of work to do, would be something that I would suggest for new teams.

The biggest lesson I have learned from using Snyk is that just when you think there are all the integrations offered in the world, there's another one. There was someone on our team that asked about an integration that they saw Snyk was offering, but it was only in their SaaS product at that time. The following month we got it in our product. They're coming out with new integrations all the time and improving the existing ones. Those are super helpful for meeting the wide range of needs across our many different teams here.

We have it running in our main repositories. We have Snyk continuously running there and scanning every commit that developers issue. We also allow developers to run the tool whenever they would like as well, on their other projects, or just to mess around with it, to get a better feel for it. We use things like TeamCity for our pipeline so we use a lot of Snyk's CLI scanning features to integrate with our tools, because some of our code bases have a little bit of a custom dependency setup. That means we have to do a couple of extra steps to get those to integrate smoothly.

Because of our custom workflows, there has been a little bit more manual work. Snyk has a lot of plugins, including a TeamCity plugin, that would be really nice to use out-of-the-box, but because of our more custom setup, we have had to do a little bit more manual work. The nice thing is that Snyk does allow us to still do that. It's not like we can only use exactly what they offer and that's it. Between their plugins and using the CLI, we're able to integrate in pretty much any environment we need.

I haven't gone through it to specifically look for false positives. Sometimes it will say there's a vulnerability and we turn out not to use that function or not to use that particular piece of that dependency.

Unfortunately, most of the containers we have scanned it against, and the ones that we use, are running an older operating system. Because the operating system is no longer actively supported, there are a lot of packages that need upgrades that we can't upgrade because we're blocked on the operating system upgrade itself. In that regard, we don't have too many actionable items from those scans. It does give us the information we need to understand how to prioritize the upgrade itself, versus upgrading the various vulnerabilities that came out of that scan.

When we have used it against some other containers, just to check as more of a one-off, it has come back with useful results. Recently there was one that had four results, and the team I was working with scanned it against multiple other tools as well, tools that they were looking at, and they all reported pretty similar things. That was good news to hear for Snyk, that we were right there and detecting everything correctly and had the same useful output.

Snyk's container security feature allows developers to own security for the applications and the containers they run in the cloud. We've been a little slow to get that fully integrated with all of our teams. We've mostly focused on our main application at the moment and I've had limited bandwidth to expand past that. But in general, both the container scanning as well as the other features of Snyk allow our teams to own their own security a little bit more, by the nature of the use of the tool and how easy it is to scan new projects or new container images. There's really nothing blocking our teams from discovering that on their own. I just haven't been able to get around to evangelizing all of the features of Snyk.

As for Snyk's lack of SAST and DAST versus the solution’s ease of use for developers, fortunately for us, we have other tools that cover those aspects and we've had those running for a while already, so we haven't really thought of those areas as lacking in Snyk. For us, it's really just been a tool that has been easy to use the whole time. If we were able to integrate more of the SAST portion especially, that would make the whole process a little bit more streamlined and potentially easier to work with. But at the moment, thankfully, we have a couple of workflows already set up for those various needs, things that really compliment each other well.

Snyk is a security software offering. It helps us identify vulnerabilities or potential weaknesses in the third-party software that we use at our company. 

The solution is meant to give you visibility into open source licensing issues, which you may not necessarily be aware off, such as the way you ingest libraries into your application code for third-party dependencies. There is visibility into anything that could be potentially exploited. 

It provides good reporting and monitoring tools which enable me to keep track of the vulnerabilities found now and/or discovered in the future. It is pretty proactive about telling me what/when something might need mitigation.

Their strength is really about empowering a very heterogeneous software environment, which is very developer-focused and where developers can easily get feedback. If you integrate their offering into the software development life cycle (SDLC), you can get pretty good coverage from a consumer perspective into the libraries that you're using.

It's a good suite of tools tailored and focused towards developers. It ensures their code is safe in regards to their usage of third-party libraries, e.g., libraries not owned or controlled, then incorporated into the product from open sources.

It is meant to be a less intrusive type of solution. It is easy to integrate and doesn't require a lot of effort. It's more a part of the CI/CD pipelines, which doesn't necessarily interfere with developers other than if there are actions/remediations to be taken. From a development impact, it's very lightweight and minimal. 

It is not noticeable for most engineers since it's part of the pipeline. If no new findings are reported, then it goes through without any signals or noise. If there were findings, these are usually legitimate findings and can be configured in such a way that they can be blocked/stopped in your pipelines or be more informational. The user has all the knobs and screws to turn and tweak it towards their use case because there may be areas where security is more critical than in other parts of the company, like development projects. 

We exclusively use their SDE tools. Our CI/CD environments are powered by source code control systems like GitLab and GitHub. BitPocket has also been integrated to some extent. There are CI/CD pipelines where we pull in Snyk as part of the pipeline, jobs, Jenkins environment, etc.

It is a fairly developer-focused product. There are pretty good support and help pages which come with the developer tools, like plugins and modules, which integrate seamlessly into continuous integration, continuous deployment pipelines. E.g., as you build your software, you may update your dependencies along with it. Packages that it supports include CI/CD toolchains, build tools, various platforms, and software/programming languages.

It is one of the best product out there to help developers find and fix vulnerabilities quickly. When we talk about the third-party software vulnerability piece and potentially security issues, it takes the load off the user or developer. They even provide automitigation strategies and an auto-fix feature, which seem to have been adopted pretty well. 

Their focus is really towards developer-friendly integrations, like plug and play. They understand the ecosystem. They listen to developers. It has been a good experience so far with them.

There were some feature requests that we have sent their way in the context of specific needs on containers, like container support and scanning support. 

There are some more language-specific behaviors on their toolchains that we'd like to see some improvements on. The support is more established on some than others. There are some parts that could be fixed around the auto-fix and automitigation tool. They don't always work based on the language used.

I would like them to mature the tech. I am involved with Java and Gradle, and in this context, there are some opportunities to make the tools more robust.

The reporting could be more responsive when working with the tools. I would like to see reports sliced and diced into different dimensions. The reporting also doesn't always fully report.

Scanning on their site, to some extent, is less reliable than running a quick CLI.

We have been engaging with Snyk for close to a year.

I have not encountered any instabilities at this point. 

We have seen cases where tools didn't find or recognize certain dependencies. These are known issues, to some extent, due to the complexity in the language or stack that you using. There are some certain circumstances where the tool isn't actually finding what it's supposed to be finding, then it could be misleading. 

As a SaaS offering, it's been fairly stable.

We have an on-prem type of broker setup, which seems to be a fairly stable. I'm not aware of any particular outages with it. 

We have no concerns regarding scalability. We operate at scale. Their approach is pretty lightweight for integrating tools locally.

We are not fully rolled out across the company; parts of the company are using it more than others. There are some best practices that we still have to establish across our development teams so it feels consistent across our scalable processes. 

I would gauge the technical support as pretty good from our interactions. We are in a licensed partnership, so the response and support that we're getting is part of our license. For quick resolutions, we have standing channels, like Slack, where we can easily get a hold of somebody who can jump in and provide some feedback. The ticketing support system is for medium to long-term requests. It's been pretty good in terms of responsiveness and their ability to support in a very reasonable time frame. Responding in less than a few hours is common in regards surfacing issues and obtaining proactive support with someone who can chime in and provide potential resolution strategies.

The product is tailored towards developers. It has a good implementation and support team who provide quick resolution on support issues. Their support listens to feedback. We engage with them, and they listen to developers' needs. They have also been pretty good in terms of turning things around. Even though we hadn't done a major request with them, they're very supportive, open, and transparent in terms of what makes sense and is reasonable, like shared priorities and roadmaps.

We have been struggling a bit with the GitLab setup, but that's more of a custom solution problem.

Their licensing model is fairly robust and scalable for our needs. I believe we have reached a reasonable agreement on the licensing to enable hundreds of developers to participate in this product offering. The solution is very tailored towards developers and its licensing model works well for us.

It addresses a lot of needs, especially in growing organizations. The more developers, the more heterogeneous your environment will look, as well as needing more tools to help you scale security practices. In this regard, it seems to be a very promising, scalable solution.

We have been utilizing the solution’s container security feature. It is not at full scale, though. We are engaging Snyk on container integrations.

I would rate it an eight (out of 10).

There are two use cases that we have for our third-party libraries:

• We use the Snyk CLI to scan our pipeline. Every time our developer is building an application and goes to the building process, we scan all the third-party libraries there. Also, we have a hard gate in our pipeline. E.g., if we see a specific vulnerability with a specific threshold (CDSS score), we can then decide whether we want to allow it or block the deal.
• We have an integration with GitHub. Every day, Snyk scans our repository. This is a daily scan where we get the results every day from the Snyk scan. 

We are scanning Docker images and using those in our pipeline too. It is the same idea as the third-party libraries, but now we have a sub-gate that we are not blocking yet. We scan all the Docker images after the build process to create the images. In the future, we will also create a hard gate for Docker images.

For the security team, it's easy to find vulnerabilities, create a report, and use the data. Every month, we have metrics. I get a report from the Snyk to see how many repositories we have scanned and how many of those repositories are violating our internal policy based on the CDSS score. I can get trends and see that we have been fixing issues. Based on that, we can then lower the score even further. It's easy to find a repository, scan, and vulnerability details associated with a particular issue using a link it provides to the database.

Snyk allows us to spend less time securing applications, increasing their productivity. It adds visibility. In addition, we can get a report and show people that our environment is a bit more secure because we have been fixing the vulnerabilities. It reduces our timing with the automation part and daily scan, which I don't have to worry about since it's always happening. We always have fresh results. Once Snyk is running, you don't have to do much. It's always there running the scans for you.

Because we now have visibility, we can create policies. Those policies are across all departments. Each department has to comply with our policies. We tweak the policy every quarter. Therefore, every quarter we try to have less high-risk vulnerabilities. By doing this, our environment is more secure. If at some point tomorrow, there's a huge unknown vulnerability, it's easy for us to go into Snyk and see if we are impacted or not.

If we have false positive, it will have a negative impact, especially if we are blocking them and it is a false positive. We really appreciate that we haven't seen any false positive coming from Snyk. The information is very reliable. 

The solution has reduced the amount of time it takes to find problems. It adds a lot of visibility. We don't have another tool providing this information. Instead of taking hours, you can find problems in a few minutes with Snyk.

The way they are presenting the vulnerabilities after a scan. It's very organized and easy to access. The UI is very organized. I also like that we can use the CLI or commands to run a scan locally or in the pipeline. 

The CLI feature is quite useful because it gives us a lot of flexibility in what we want to do. If you use the UI, all the information is there and you can see what Snyk is showing you, but there is nothing else that you can change. However, when you use the CLI, then you can use commands and can get the output or response back from Snyk. You can also take advantage of that output in a different way. For the same reason, we have been using the CLI for the hard gate in the pipeline: Obtain a particular CDSS score for vulnerability. Based on that information, we can then decide if we want to block or allow the build. We have more flexibility if we use the CLI.

For the pipeline, we use Jenkins, and for storing images in the build, we use Artifactory with some Jenkins integrations. This is super easy because we are using the CLI, which was one of the features that I really like because it's super flexible. You can do a lot of things with the CLI. It's easy to integrate. Same thing with the GitHub integration, Snyk provides Broker images that allow you to coordinate your internal GitHub repository with the cloud solution from Snyk. It's like a proxy.

The UI is super easy to use. I have no issues with the interface.

The way Snyk notifies if we have an issue, there are a few options: High vulnerability or medium vulnerability. The problem with that is high vulnerabilities are too broad, because there are too many. If you enable notifications, you get a lot of notifications, When you get many notifications, they become irrelevant because they're not specific. I would prefer to have control over the notifications and somehow decide if I want to get only exploitable vulnerabilities or get a specific score for a vulnerability. Right now, we receive too many high vulnerabilities. If we enable notifications, then we just get a lot of spam message. Therefore, we would like some type of filtering system to be built-in for the system to be more precise.

The same thing applies to policies when you go to the dashboard: Everything is red. Because of the nature of our third-party library, most of them have high security issues. However, too many are identified. Snyk needs to provide a way to add some granularity so you can decide what is relevant.

A year.

So far, it's very stable. We haven't had any issues with the platform.

Deployment and maintenance is done by the security team and DevOps.

We are using them all the time and scalability has not been a problem. I am pretty sure they will keep supporting our company with all our daily scans. I don't see any issues with scalability.

We do have plans to increase the usage. For just our GitHub repository, we are scanning more than 700 repos. We will probably expand that to 1000 or more repos.

Developers go to Snyk only if there is a need regarding a specific vulnerability. Developers do not normally use Snyk. Our security team uses Snyk more often. Snyk tries to put this tool towards developers, but there are not that many developers using this tool compared to the security team.

Since we have been adding this CLI to the pipeline and scanning the entire build, most developers have been creating an Snyk account in our organization. Since we are sort of forcing this on them, they need to have access. They have been using it but only if they get a block or need to fix a vulnerability. The account integration is easy for them to request access to and the process is quick.

We have 120 users, including the whole security team, the cloud operations team, DevOps, a lot of developers, and user members.

The technical support is really good. They are very quick. They take care of you. If there is an issue, they will try to solve it.

Our company did not use anything before Snyk.

I have used Nexus IQ in another company.

The initial setup is easy and straightforward. The documentation is very specific with the commands for the CLI. They provide support, if you have any questions. I was always talking with somebody from the Snyk. 

We use a sliding configuration between our company and Snyk, so the communication is super easy. Most of the time, they have already documented the issue or how-to. Or, if you have an extra question, they are super quick responding back to you.

The deployment for Snyk's hard integration was a week. Building the hard gate and sub-gate took a little bit longer (about a month) just to have everything integrated, but they were not fully dedicated when they did integration. If you really need to do the integration, you can probably do it in a couple of weeks.

Implementation strategy: We started with the third-party library solutions from Snyk. Now, we are moving to the container solution.

We have not seen ROI yet.

You can get a good deal with Snyk for pricing. It's a little expensive, but it is worth it.

Snyk's vulnerability database is pretty accurate. I have used other tools in the past and they were not that accurate or specific. Sometimes, I was not sure if something was a false positive or not. However, Snyk is very strong on this sense. I haven't seen any false positives.

If we find an issue, then we talk to our developers who have a specific amount of days to fix the vulnerability. However, we are not fully using all the features that Snyk provides. While I know they could make a suggestion or do automation to fix issues, we are not using those features.

Snyk has really nice features. They take into consideration what customers are telling or suggesting to them. It's a very good product. I would rate it a nine (out of 10).

Snyk acts as an SCA and also as a SAST. It's like a mix and match.

Our deployment is more of a hybrid deployment. It is 70% cloud and 30% on-prem. The majority of Snyk is a cloud-based solution, but we do have instances where we have it on-prem for various reasons.

The advantage of Snyk is that Snyk automatically creates a pull request for all the findings that match or are classified according to the policy that we create. So, once we review the PR within Snyk and we approve the PR, Snyk auto-fixes the issue, which is quite interesting and which isn't there in any other product out there. So, Snyk is a step ahead in this particular area. In the development phase, there are lots of dependencies from one module to another, and if it has to be a manual fix, it takes forever for developers to fix it. We do utilize both functionalities. Sometimes, I get the developers to look at the issues and get them manually fixed, and sometimes, based on the criticality and severity of the finding, I just approve the PR, and Snyk automatically fixes it. I don't need to worry about the dependencies.

All such tools should definitely improve the signatures in their database. Snyk is pretty new to the industry. They have a pretty good knowledge base, but Veracode is on top because Veracode has been in this business for a pretty long time. They do have a pretty large database of all the findings, and the way that the correlation engine works is superb. Snyk is also pretty good, but it is not as good as Veracode in terms of maintaining a large space of all the historical data of vulnerabilities.

I have been using this solution for about two years. 

It is easily scalable, and it is pretty easy to integrate and manage. However, the tuning is what requires a lot of attention. Snyk, Veracode, Netsparker, or any other similar solution definitely needs somebody to tune it to work properly. Tuning is a little bit tricky, but that's the nature of such solutions.

I had to work with them initially during the integration phase. Their support was okay. It was not that good, but it was also not that bad. There is room for improvement because the support works based on the categories of requests. Along with the categories, if they have an option for the sensitivity or the urgency of issues, it would be really helpful for users.

It was pretty easy. 

It is pretty expensive. It is not a cheap product.

I would rate it a seven out of ten.