Snyk Reviews

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.

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

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

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

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

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

The most valuable features are their GitLab and JIRA integrations.

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

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

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

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

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

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

I have been using Snyk for about a year.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.