Snyk Reviews

We are using Snyk to find the vulnerabilities inside dependencies. It is one of the best tool in the market for this. 

It is pretty easy and straightforward to use because integration won't take more than 15 minutes to be honest. After that, developers don't have to do anything. Snyk automatically monitors their projects. All they need to do is wait and see if any vulnerabilities have been reported, and if yes, how to fix those vulnerability. 

So far, Snyk has given us really good results because it is fully automated. We don't have to scan projects every time to find vulnerabilities, as it already stores the dependencies that we are using. It monitors 24/7 to find out if there are any issues that have been reported out on the Internet.

Whenever Snyk reports to us about a vulnerability, it always reports to us the whole issue in detail:

• What is the issue.
• What is the fix.
• What version we should use.

E.g., if upgrading to a new version may break an application, developers can easily understand the references and details that we receive from Snyk regarding what could break if we upgrade the version.

The solution allows our developers to spend less time securing applications, increasing their productivity. As soon as there is a fix available, developers don't have to look into what was affected. They can easily upgrade their dependencies using Snyk's recommendation. After that, all they need is to test their application to determine if the new upgrade is breaking their application. Therefore, they are completely relaxed on the security side. 

Snyk is playing a big role in our security tooling. There were a couple of breaches in the past, which used vulnerability dependencies. If they had been using Snyk and had visibility into what vulnerabilities they had in their dependencies, they could have easily patched it and saved themselves from their breaches.

So far, we have really good feedback from our developers. They enjoy using it. When they receive a notification that they have a vulnerability in their project, they find that they like using Snyk as they have a very easy way to fix an issue. They don't have to spend time on the issue and can also fix it. This is the first time I have seen in my career that developers like a security tool.

I'm the only person who is currently maintaining everything for Snyk. We don't need more resources to maintain Snyk or work full-time on it. The solution has Slack integration, which is a good feature. We have a public channel where we are reporting all our vulnerabilities. This provides visibility for our developers. They can see vulnerabilities in their projects and fix them on their own without the help of security.

Snyk integrations and notifications with Slack are the most valuable feature because they are really handy. By monitoring dependencies, if there is a vulnerability reported, Snyk will fire off a Slack message to us. With that Slack message, we can create a request just from the notifications which we receive on Slack. It's like having visibility in a general channel and also flexibility to fix that issue with a few clicks.

The solution’s vulnerability database is always accurate since the chances of getting a false positive is very rare. It only reports the vulnerabilities which have already been reported publicly.

The solution’s Container security feature allows developers to own security for the applications and the containers they run in in the cloud. Without using Snyk, developers might be not aware if they are creating a vulnerability in their Docker images. While using Snyk, they have at least a layer of protection where they can be notified by a Snyk if there is a vulnerability in the Docker images or communities.

If the Snyk had a SAST or DAST solution, then we could have easily gone with just one vendor rather than buying more tools from other vendors. It would save us time, not having to maintain relationships with other vendors. We would just need to manage with one vendor. From a profitability standpoint, we will always choose the vendor who gives us multiple services. Though, we went ahead with Snyk because it was a strong tool.

Snyk needs to support more languages. It's not supporting all our languages, e.g., Sift packages for our iOS applications. They don't support that but are working to build it for us. They are also missing some plugins for IDEs, which is the application that we are using for developers to code.

There are a couple of feature request that I have asked from Snyk. For example, I would like Snyk to create a Jira ticket from Slack notifications. We already have Snyk creating a pull request from Slack notifications, so I asked if we could create a Jira ticket as well so we can track the vulnerability.

I started working with at my company eight months ago and Snyk was already in place. As for my own experience, I was using this solution before I joined the company, so I was familiar with the tool and how it works.

They were a couple of issues which happened because Snyk lacked some documentation on the integration side. Snyk is lacking a lot of documentation, and I would like to see them improve this. This is where we struggle a bit. For example, if something breaks, we can't figure out how to fix that issue. It may be a very simple thing, but because we don't have the proper documentation around an issue, it takes us a bit longer.

So far, we have onboarded all our developers to Snyk, and it's still running fine. However, they could improve it. For example, if I create a bulk request for more than 15 or 20 vulnerabilities, then it takes a bit longer than it should in terms of time.

Including security, the total developers that we have on Snyk is almost 50 at this time. We are pushing more to the developers and would like to have 200 developers in the coming month or two.

The people with whom I'm connected are really good. If I have issues, they will quickly jump on a call and I will start troubleshooting with them over the call. The people with whom I'm talking are very technical.

Before using Snyk, we didn't have visibility into how many dependencies we were using or importing into our projects. Snyk gives us how many third-party libraries we are using and what version they are running on. Also, it let us know if there are any vulnerabilities in those libraries when we are writing our code. Because of the potential impact, we have to ensure that there aren't any vulnerabilities in these libraries (since we have no visibility) when we are importing. 

The initial setup was straightforward. Onboarding projects didn't take me too long. It was pretty straightforward and easy to integrate with event/packet cloud and import all our projects from there. Then, it was easy to generate the organizational ID and API key, then add it to the Snyk plug-in that we are using in our build pipeline.

Snyk was already onboard when I joined. Deployment of my 23 projects took me an hour. 

The solution has reduced the amount of time it takes to find problems by three or four hours per day. 

The solution has reduced the amount of time by at least two to three hours a day to fix problems because the documentation which we receive is very helpful. This also depends on a couple of factors, such as, how big a project or library is.

Developer productivity has increased a lot. Considering all the projects about security vulnerabilities, we are saving at least six to seven hours a day.

It saves a lot of my time and the developers' time. Also, because everything is super simple and straightforward in one place, it is really convenient for the security team to keep an eye on vulnerabilities in their projects.

Having this type of tool for a security team is really helpful. In my previous role, we didn't have this type of tool for our team. We struggled a lot with how we could enhance our visibility or see our projects: what dependencies they were using and if we could monitor those dependencies for any vulnerabilities. Without the tool, we could be attacked by some random vulnerability which we were not even aware of. Thus, I strongly recommend having this type of tool for a security team.

This is integrated with our CI/CD.

For Containers, we are still not fully rolled out and working around it. 

I would rate this solution as a seven (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.

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.

I have used Snyk in my present and past workplace, along with Veracode, Checkmarx, and GitHub Advanced Security. The main product that really brought Snyk to market was software component scanning for third-party components, however I like the new things that they're doing as well.

They've got container scanning, which they're just now starting to do, and they're also bringing in new use cases such as static analysis (i.e. SAST) and secrets scanning, although I don't know exactly what's happening on that side of things.

In my previous workplace, we had about 100 users as it was still being scaled up and it was a relatively new product at the time. As for the version number, we use the latest version of Snyk since it is a cloud-based SaaS offering which is always kept up to date.

I think all the standard features are quite useful when it comes to software component scanning, but I also like the new features they're coming out with, such as container scanning, secrets scanning, and static analysis with SAST.

The most prominent reason why everybody goes with Snyk as a starting point is because they have an open source offering. As such, it's a developer-friendly solution and our developers really like it for that. In my opinion, that's their very first 'in' from all the avenues within the Software Development Life Cycle, because they deliberately make it developer-friendly from the start, and allow for lots of integration which fits with other tools.

For the areas that they're new in, it's very early stages for them. For example, their expertise is in looking at third-party components and packages, which is their bread-and-butter and what they've been doing for ages, but for newer features such as static analysis I don't think they've got compatibility for all the languages and frameworks yet.

That's something I believe will be expanding over time, but I'm not 100% sure when they're going to get to it. Thus, my main concerns for improvement would definitely be greater language and framework coverage, and on a lesser note I would also like to see a reduced number of false positives on their scans.

Then there's the issue of their support. It's not very good, to be honest, and it hasn't been the best experience to deal with them. I think they need to develop proper customer success managers when it comes to Service Level Agreements and how they engage with their customers. On the other hand, their technical support is okay as all the technical aspects are essentially all written down and you just have to follow them. 

I've been using Snyk for three years up until now.

We've had no issues with stability. You can run it with the CLI or the GUI and the stability is very good on both.

We have successfully scaled it up to 100 users before, so I would say it is scalable. 

Our experience with their customer support wasn't the best. My opinion is that they need to develop their customer support channels better, by providing customer success managers to better engage with their customers, for example.

Otherwise, the technical support is adequate. Most of the issues we've encountered were able to be worked out by our own developers since the technical documentation is all written out and simply needs to be followed. 

When it comes to installation, Snyk is very good. It's probably one of the easiest, most developer-friendly solutions to install.

I didn't think the price was that great, but it wasn't that bad, either. I'd rate their pricing as average in the market.

Overall, Snyk is a satisfactory solution that I believe could be improved by reducing the number of false positives and extending coverage for more languages and frameworks.

I would rate Snyk a seven out of ten.

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).

The major problem my company found in relation to our customers was in the area of Zip Slip security as they don't have any security tools in place. My company's customers don't have any security tools integrated into the CI/CD pipelines they use in their company. With Snyk, SCA checks code and third-party dependencies upfront.

When it comes to Snyk, it is not about its features since it is a developer-focused tool, making it possible for developers to easily integrate the tool with other solutions. The automation part and reporting feature of the solution are good. Nowadays, people opt for Cloud Native Pod system architecture, under which good tools are offered to users to use for their applications.

I think Snyk should add more of a vulnerability protection feature in the tool since it is an area where it lacks. Snyk needs to focus on the area related to dependencies.

I have been using Snyk for ten years.

Snyk is a good and scalable tool. Some of our customers who get to use the scalability options go ahead and compare Snyk with other options like Veracode, which is a highly expensive tool that is also complex. Snyk is a simpler tool compared to Veracode.

My company deals with mostly medium-sized clients who use Snyk.

In our company, the team I deal with, the delivery team, has never raised concerns regarding the support offered by Snyk. I hope the support offered by Snyk is fine.

My company has dealt with SonarQube a lot in the past. It is not that my company switches over from one tool to another tool. The tools we use in my company depend on our customers. Some of my company's customers prefer SonarQube, while others prefer Snyk.

The product's initial setup phase was easy.

The solution's deployment model varies from customer to customer. My company deals with a mix of clients, some of whom deploy the tool on the cloud while others deploy it on an on-premises model.

Compared to Veracode, Snyk is definitely a cheaper tool. SonarQube's community version or enterprise version is mostly used, but price-wise, it is okay. The price depends on how many lines of code a customer uses in SonarQube.

The major reason why customers prefer Snyk is that, nowadays, people are moving towards cloud-native tools. People also want a tool that offers safety and security, especially during the integration process and during the coding part. Snyk offers a set of much better features when compared to other tools like SonarQube or Veracode. Smaller companies can choose the team plan or enterprise version offered by Snyk. The major reason why people prefer Snyk is because of the security it offers.

I rate the overall tool a six or seven out of ten.

It is for SCA, and we have just been doing the PoC. We are currently using the open-source version for some of the development teams. 

The main functionality that we found useful is scanning. A main feature of Snyk is that when you go with SCA, you do get properly done security composition, also from the licensing and open-source parameters perspective. A lot of companies often use open-source libraries or frameworks in their code, which is a big security concern. Snyk deals with all the things and provides you with a proper report about whether any open-source code or framework that you are using is vulnerable. In that way, Snyk is very good as compared to other tools.

I had a list of what they can improve, and I did share that with them. They are coming up with a beta version. 

It can be improved from the reporting perspective and scanning perspective. They can also improve it on the UI front. When we started the PoC five months ago, we encountered all these things. So, I asked them to improve on them. They have come up with a lot of new features, but they are still lacking on the UI front and the reporting side of things.

If you go to the UI front of Snyk, you won't find it so friendly. Another one is that you can't see the projects clearly. It gets all the sources from the repository. It pulls all the projects from the repository and creates a new project altogether for every new addition. So, you can't group them clearly. For example, if I have one product with different repositories, it creates a number of projects underneath in the Snyk UI. 

When it comes to reporting, if I run a scan on a particular project, I want the report only for that particular project in a PDF format that I can share with others. Currently, you get the notification over an email with all the projects but not in detail. You have to go to Snyk to find the details of a particular project. You only get a generic view, and you don't get a detailed view of a project. You need to go to the tool, export it as a CSV, and then find it, which is ridiculous. With other tools, once the scan is complete, we can just share the report with the development team that is working on that project, but Snyk doesn't let us do that. They still need to work a lot on the reporting structure.

It also needs to be improved in terms of interdependencies. When you run a code scan, the code can have interdependencies. If you have found a vulnerable line somewhere, it might lead to other interdependencies. Currently, Snyk doesn't provide you with interdependencies. For example, it doesn't provide you with the best location to do the fix. Checkmarx does that, and after you fix a particular line of code, all the other dependencies are automatically fixed. Snyk doesn't offer that. So, you have to do the fix one by one, which is a tedious task for the development team. It takes a lot of effort. I shared this feedback with them, and they might be working on it. They told me that they'll consider that.

We have been using Snyk for the past five months.

They are very proactive, sometimes more than what we want them to be. They reach out to us very often, and they are very good with technical support. They reach out to us and just ask us if there are any challenges where they can improve. They're quite open on that front. They don't have any local support as of now, but they are planning for 24/7 support. Currently, they are based only in the US, but they are still very active. Whenever we send out an email, they respond immediately. I would rate them a four out of five.

Positive

I have worked with other solutions. From the open-source composition and the licensing perspective, they are doing well as compared to competitors such as Black Duck, Veracode, and others. They do well on that front.

Checkmarx is the top one. They need to work very hard to match Checkmarx. Checkmarx is really good as compared to Snyk, but Checkmarx is too expensive. That's the reason we went with Snyk. Checkmarx has a very good scanning engine and technical support. It is also user-friendly. It is quite friendly for developers who are beginners. Anyone can use and learn Checkmarx easily, whereas with Snyk, you need some knowledge before you begin with it.

I had an on-prem Checkmarx. They still do on-prem, and now, they're also coming up with the cloud version. Even if you use the on-prem version, it is quite easy to access the database. You can customize everything based on your needs. From the scanning perspective, if I want to change any policies or rules, it is quite easy with Checkmarx. You just need to change the query inside the database, and you can easily set the rules.

We have only done a PoC. We are yet to finalize the pricing and then deploy the product as a whole. When it comes to PoC, it was quite simple. It was not complex at all. The integrations with GenCAN, or even with GitHub, were quite easy for us. There was no complex structure there. It was straightforward. Once we set up the environment, it took us a few hours to do all the integrations with different repositories or CI/CD. I would rate it a four out of five in terms of ease of the setup.

Currently, we have done it on CI/CD. It is kind of automated. Whenever there is a new build, it automatically triggers the scan.

There are about 30 developers who have been working with it for the PoC. They have been using it on a daily basis for the past four months. Last month, we stopped using it because we have finalized it. Going forward, we will be having 500 developers to begin with. 

We did the integration using their documentation. Their documentation was very simple. It was very easy to use.

We are using the open-source version for the scans. We will be going with the full source, license-based version as soon as possible.

I would rate it a seven out of ten.

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.