Snyk Reviews

The use cases for Snyk are quite progressive. I'm pretty much happy with the solution's performance with SaaS products.

Snyk performs software composition analysis (SCA) similar to other expensive tools.

Snyk can be improved on the reporting aspect regarding the traceability of SCA. It also doesn't have storage. For instance, if you are scanning version 'X' and then you're scanning on another version 'X+1', it doesn't store your information. It doesn't compare particular vulnerabilities between 'X' and 'X+1'. Snyk is helpful and quite handy for people on the development team. The solution's reporting and storage could be improved.

The next release of Snyk should have more training features for developers. The tool offers software composition analysis, and though it says what needs to be fixed, it's in a reactive space. Since DevSecOps has become a culture nowadays, and the industry is going more towards proactive measures, the developers need to be trained.

I have been using Snyk for around a year now.

During our POC, I found no stability issues like application downtime or lags. I rate Snyk a nine out of ten for stability.

I rate Snyk a nine out of ten for scalability. Our clients are enterprise businesses. In the POC state, we don't have an exact number of users because we have one license, but otherwise, five users use Snyk.

A technician was allotted to us, and he responded promptly to our queries and gave timely information. I rate Snyk a nine out of ten for its customer support.

Positive

The support extended during the POC period was excellent, and we had people supporting us because we needed to add another pipeline channel. Snyk's support feature was really good. Leaving aside certain areas of reporting, I rate the initial setup an eight out of ten.

Once you get the license, it's completely the developer or DevOps team's work to deploy it. The complete process takes two days, but the Snyk site does the deployment in a matter of hours. You purchase the SNC license, which is deployed on the cloud, and then you can call those APIs in your CI pipeline. You can always have it integrated. Once your license is enabled, you have to give access to that particular user.

Despite Snyk's coverage, scalability, reliability, and stability, it is available at a very competitive price. According to the Snyk website, the regular licensing cost is around $ 39 and around $74 per user for CI/CD, with a minimum commitment of five users.

I have not seen any additional costs to the standard licensing fees in our agreement. I need to wait till our agreement renewal to answer this question more effectively.

Snyk is a cloud product. AWS is the cloud provider for Snyk.

People should consider using the scalable model of Snyk for SCA before considering other tools. If you are in the initial security phase or newly setting it up for practice in your organization, I recommend starting with Snyk. Anyone starting into the market and not wanting to invest in a large amount should consider Snyk as an alternative. Snyk is a good tool that provides equivalent security standards compared to other expensive tools.

I've seen the evolution of Snyk in the last four to five years. They started with software composition analysis and have now integrated static application security testing. They have partnerships with various dynamic security testing companies like StackHawk, Rapid7, and InsightAppSec. Snyk is progressive, and they have a good R&D team. I work for a service-based organization, where my job is to understand the customer's pain points and provide consultation. Most customers' pain points are the trade-off between cost and security compliance. Most customers come with financial constraints, and at least a few are opting for Snyk as an option because they were able to get the desired results. And Snyk is doing a pretty good job concerning the standard these customers need to extend to their partners.

Overall, I rate Snyk an eight out of ten.

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.

We are using Snyk for two main reasons: 

1. Licensing. For every open source package that we're using, we have licensing attributions and requirements. We are using Snyk to track all of that and make sure we're using the licenses for different open source packages that we have in a compliant fashion. This is just to make sure the licensed user is correct. 
2. Vulnerabilities. Snyk will report on all the vulnerabilities present in all our different packages. This is also something we'll use to change a package, ask the desk to fix the vulnerability, or even just block a release if they are trying to publish code with too many vulnerabilities.

I am using the latest SaaS version.

Our whole process of deploying code uses Snyk either as a gateway or just to report on different build entities. 

The solution's ability to help developers find and fix vulnerabilities quickly is a great help, depending on how you implement it at your company. The more you empower your developers to fix their stuff, the less policies you will have to implement. It's a really nice feeling and just a paradigm shift. In our company, we had to create the habit of being proactive and fixing your own stuff. Once the solution starts going, it eases a lot of management on the security team side.

Snyk's actionable advice about container vulnerabilities is good. For the Container tool, they'll provide a recommendation about what you can do to fix your Docker, such as change to a slimmer version of the base image. A lot of stuff is coming out for this tool. It's good and getting better.

The solution’s Container security feature allows developers to own security for the applications and the containers they run in in the cloud. That is its aim. Since we are letting the developers do all these things, they are owning the security more. As long as the habit is there to keep your stuff up-to-date, Snyk won't have any effect on productivity. However, it will have a lot of effect on security team management. We put some guardrails on what cannot be deployed. After that, we don't have to check as much as we used to because the team will just update their stuff and try to aim for lower severities.

Our overall security has improved. We are running fewer severities and vulnerabilities in our packages. We fixed a lot of the vulnerabilities that we didn't know were there. Some of them were however hard to exploit, mitigating the risks for us, e.g., being on a firewalled server or unreachable application code. Though I don't recall finding something where we said, "This is really bad. We need to fix it ASAP."

I find many of the features valuable: 

• The capacity for your DevOps workers to easily see the vulnerabilities which are impacting the code that they are writing. This is a big plus. 
• It has a lot of integration that you can use even from an IDE perspective and up to the deployment. It's nice to get a snapshot of what's wrong with the build, more than it is just broken and you don't know why. 
• It has a few nice features for us to manage the tool, e.g., it can be integrated. There are some nice integrations with containers. It was just announced that they have a partnership with Docker, and this is also nice. 

The baseline features like this are nice. 

It is easy to use as a developer. There are integrations that will directly scan your code from your IDE. You can also use a CLI. I can just write one command, then it will just scan your old project and tell you where you have problems. We also managed to integrate it into our build pipeline so it can easily be integrated using the CLI or API directly, if you have some more custom use cases. The modularity of it is really easy to use.

Their API is well-documented. It's not too bad to integrate and for creating some custom use cases. It is getting extended going forward, so it's getting easier to use. If we have issues, we can contact them and they'll see if they can change some stuff around. It is doing well.

Most of the solution's vulnerability database is really accurate and up-to-date. It has a large database. We do have some missing licenses issues, especially with non-SPDX compliant one, but we expect this to be fixed soon. However, on the development side, I rarely have had any issues with it. It's pretty granular and you can see each package that you're using along with specific versions. They also provide some nice upgrade paths. If you want to fix some vulnerabilities, they can provide a minor or major patch where you can fix a few of them.

• More visibility on the package lifecycle because we are scanning our application at different point (DevOps, Security, QA, Pipeline, Production Env) and all those steps get mixed together in the UI. Therefore, it's hard to see the lifecycle of your package.

• Docker base image support was missing (Distroless) but support is increasing.

• UI taking some time to load. We have a lot of projects in the tool.

Snyk is responsive and they work to fix the pain points we have.

For two years.

The stability is good. I don't recall ever having issues with the application being unreachable or down.

Scalability has some issues because we have a lot of code and its use is mandatory. Therefore, it can be slow at times, especially because there are a lot of projects and reporting. Some UI improvements could help with this. 

From a scan time perspective, everything is pretty fast.

All our developers and the security team use it. There are probably around 100 people using it whose roles are mainly developers, along with a few security analysts and architects.

We have good communication with Snyk. They make us feel like a valued customer and provide us with a Customer Success Manager and training for our teams.

I haven't contacted technical support. One of my teammates did contact them and was pleased with the results. 

We were previously using another vendor for vulnerability management. We decided to use Snyk in parallel to handle licence reporting. One issue that we had with our previous vendor was that we were promised features that were never delivered. It also had some quirks that weren't fitting our needs. Since we already had Snyk, and it could do vulnerability reporting, we decided to keep Snyk for the two use cases.

I wasn't part of the initial setup. It was done by another team. From what I heard, it wasn't too much of a hassle to set up. Though, my team hasn't been 100 percent satisfied with how it was set up by us, as we could do so much more with the tool..

We have seen ROI from a security perspective.

The solution has reduced the amount of time it takes to find and fix problems, especially to fix them. Without Snyk, we had no visibility on open source package vulnerabilities. We started from not seeing anything to fixing them. Since we had to wait for an incident or fortuitous discovery before, it has been a good improvement.

At first, we were using it only for scanning the images that were getting sent to production. Then, we added the entire workload running on our clusters. This increased our vulnerabilities because there were duplicates, but also gave more visibility.

The more you put into learning the tool, the better results you will get. Even if it's easy to use, you do need to create the habit of using it with your DevOps. Once it's integrated, it will be a lot easier. You'll see quickly the issues that you can fix when you're writing your code and don't have to wait until the end of QA to be denied.

I don't see anything Snyk can report as a false positive because the vulnerability database is there and the vulnerable code in the package. It just depends on how you invoke the code. Unless they start scanning the code, they cannot know. From that perspective, false positives are pretty low, almost non-existent.

Our developers are spending more time working on Snyk issues than before, mainly because they were not aware of things that they needed to fix. The process is easy to fix something, so it neither increases nor decreases our developer productivity.

It does require a bit of time, especially when creating the habit of using the tool, but the investment is worth it. It enables developers to own security. If you can get the developers to own security, you are reducing a lot of weight off of your security team. Then, you don't need to have such a big security team because the solution offloads a lot of work.

Get the developers on your side. We managed to make it mandatory, but this won't happen everywhere. If a developer takes a solution to heart in a project and really wants to use it, it'll go well. Otherwise, if you keep fighting against them, then it will be a hassle.

If Snyk offered a SAST/DAST solution, we would be interested in testing it out. We have good experience with the platform and we could consolidate our efforts with them. We are not super satisfied with our current SAST implementation.

What I want for the future is to get more proactive adoption instead of adopting because it is mandatory. Adoption will grow, especially if Snyk have other features coming in. We enjoy the product.

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