We just raised a $30M Series A: Read our story

Snyk OverviewUNIXBusinessApplication

Snyk is the #2 ranked solution in our list of Container Security Solutions. It is most often compared to SonarQube: Snyk vs SonarQube

What is Snyk?

Snyk’s mission is to help developers use open source code and stay secure. The use of open source is booming, but security is a key concern (https://snyk.io/stateofossecurity/). Snyk’s unique developer focused product enables developers and enterprise security to continuously find & fix vulnerable dependencies without slowing down, with seamless integration into Dev & DevOps workflows. Snyk is adopted by over 100,000 developers, has multiple enterprise customers (such as Google, New Relic, ASOS and others) and is experiencing rapid growth. Our investors are Canaan Partners, BOLDStart, and several successful developer tools entrepreneurs. Snyk was founded in 2015 and is headquartered in London with offices in Israel and the US. For more information, go to https://snyk.io/.

Snyk Buyer's Guide

Download the Snyk Buyer's Guide including reviews and more. Updated: September 2021

Snyk Customers

StartApp, Segment, Skyscanner, DigitalOcean, Comic Relief

Snyk Video

Pricing Advice

What users are saying about Snyk pricing:
  • "It's good value. That's the primary thing. It's not cheap-cheap, but it's good value."
  • "With Snyk, you get what you pay for. It is not a cheap solution, but you get a comprehensiveness and level of coverage that is very good. The dollars in the security budget only go so far. If I can maximize my value and be able to have some funds left over for other initiatives, I want to do that. That is what drives me to continue to say, "What's out there in the market? Snyk's expensive, but it's good. Is there something as good, but more affordable?" Ultimately, I find we could go cheaper, but we would lose the completeness of vision or scope. I am not willing to do that because Snyk does provide a pretty important benefit for us."
  • "Snyk is a premium-priced product, so it's kind of expensive. The big con that I find frustrating is when a company charges extra for single sign-on (SSO) into their SaaS app. Snyk is one of the few that I'm willing to pay that add-on charge, but generally I disqualify products that charge an extra fee to do integrated authentication to our identity provider, like Okta or some other SSO. That is a big negative. We had to pay extra for that. That little annoyance aside, it is expensive. You get a lot out of it, but you're paying for that premium."
  • "We do have some missing licenses issues, especially with non-SPDX compliant one, but we expect this to be fixed soon"
  • "You can get a good deal with Snyk for pricing. It's a little expensive, but it is worth it."

Snyk Reviews

Filter by:
Filter Reviews
Industry
Loading...
Filter Unavailable
Company Size
Loading...
Filter Unavailable
Job Level
Loading...
Filter Unavailable
Rating
Loading...
Filter Unavailable
Considered
Loading...
Filter Unavailable
Order by:
Loading...
  • Date
  • Highest Rating
  • Lowest Rating
  • Review Length
Search:
Showingreviews based on the current filters. Reset all filters
Nicholas Secrier
Information Security Officer at a tech services company with 51-200 employees
Real User
Top 5
Helps Avoid The Pain And The Cost Of Trying To Retrofit Security in your Code.

Pros and Cons

  • "The dependency checks of the libraries are very valuable, but the licensing part is also very important because, with open source components, licensing can be all over the place. Our project is not an open source project, but we do use quite a lot of open source components and we want to make sure that we don't have surprises in there."
  • "Generating reports and visibility through reports are definitely things they can do better."

What is our primary use case?

We are using it to identify security weaknesses and vulnerabilities by performing dependency checks of the source code and Docker images used in our code. We also use it for open-source licensing compliance review. We need to keep an eye on what licenses are attached to the libraries or components that we have in use to ensure we don't have surprises in there.

We are using the standard plan, but we have the container scanning module as well in a hybrid deployment. The cloud solution is used for integration with the source code repository which, in our case, is GitHub. You can add whatever repository you want to be inspected by Snyk and it will identify and recommend solutions for your the identified issues. We are also using it as part of our CI/CD pipelines, in our case it is integrated with Jenkins. 

How has it helped my organization?

As the developers work they can run the checks and they can validate if their work meets our expectation or not. Then they can address the potential issues during development, rather than going through the whole process and then being pushed back and told, "Hey, you've got issues in here. This is an old component that is no longer supported," or "It's something that has a vulnerability." From that point of view, it's very valuable.

I'm not a developer, I'm an information security officer, but the false positive rate seems to be pretty good. Generally, when it picks up something, it's there. Snyk is not an antivirus. When it highlights something then there is a problem. Sometimes you can fix it, sometimes you cannot fix it. The good thing is that at least you are aware that there is a potential issue. If it's something serious, you can try to validate, but you can usually validate the issue against other databases by looking at a CVV. You've got enough information to identify if this is a real problem or not. In the vast majority of the cases, if you look at dependency, it's pretty straightforward. It matches the database that is being picked up, and you can have a look at more details.

Generally, security tools don't necessarily end up in increased productivity. What Snyk prevents is the wasting of time or productivity. If you're trying to go back and fix issues that are caused by potential vulnerabilities discovered by a pen test, trying to retrofit security can be quite painful. From that point of view, you may go a little bit slower because it's an extra step, but at the same time, you save time on the overall process and you're saving exposing the company to risks.

As a tool, Snyk allows us to identify areas where we need to improve, and this could be at the vulnerability level if there is a library that has a vulnerability. It also helps us with the licensing compliance, identifying if the new components that have been added to the code meet our company's open source compliance. In those ways it helps us as a company. The overall impact of Snyk depends on the way you use it. To me, it's the users, not Snyk, doing something.

We are a new company. We started roughly three years ago. But we knew security is a very important factor. We work with some very large companies out there. Privacy and security of their data is very important. Security was something that we knew we had to put in place from the beginning, as a way of demonstrating that we take things seriously. And we also satisfy the needs of our investors and clients when it comes to trusting us as a provider.

What is most valuable?

The dependency checks of the libraries are very valuable, but the licensing part is also very important because, with open source components, licensing can be all over the place. Our project is not an open source project, but we do use quite a lot of open source components and we want to make sure that we don't have surprises in there. That's something that we pay attention to.

The ease of use for developers is quite straightforward. They've got good documentation. It depends on the language that you use for development, but for what we have — Java, JavaScript, Python — it seems to be pretty straightforward.

It also has good integration with CI/CD pipelines. In the past we had it integrated with Concourse and now it's running on Jenkins, so it seems to be quite versatile.

What needs improvement?

They've recently launched their open source compliance. That's an area that is definitely of interest. The better the capability in that, the better it will be for everyone. There may be room to improve the level of information provided to the developers so they understand exactly why using, say, a GPL license is a potential issue for a company that is not intending to publish its code.

There is potential for improvement in expanding the languages they cover and in integrating with other solutions. SonarQube is something that I'm quite interested in, something that I want to bring into play. I know that Snyk integrates with it, but I don't know how well it integrates. I will have to see.

Generating reports and visibility through reports are definitely things they can do better.

For how long have I used the solution?

We've been using Snyk for nearly two years.

What do I think about the stability of the solution?

Generally, the stability of Snyk is fine. From time to time the reporting bits, when you look at them on the cloud, can be a little bit sluggish when you start having quite a bit of information in there. But there have been no major outages when we couldn't use it. I don't know if the sluggishness is internet-related or it's something within Snyk. They are based in the United States and I don't know if the traffic across the pond is causing any of these issues.

It's not something that you constantly use all the time. When you want to commit something, it runs on a schedule. When you put something through the pipeline, it runs. But again, there have been no outages or issues with the stability.

What do I think about the scalability of the solution?

We have had no issues with scalability. We haven't needed to do anything special to address that. So far, we have had no problems.

Usage, in our case, will depend on the number of developers that we have. So unless Snyk develops additional features, something more we can use, and we expand because of those capabilities, I don't see a massive increase in our user base. It's a development-orientated solution with a small number of people, from management, who generally keep an eye on the reports, from a compliance point of view. It all depends on our company. The only impact that will come from Snyk is if it comes out with new features that we would like to implement.

How are customer service and technical support?

We had some chats with technical support at the beginning. They seemed to be pretty responsive. Generally, you communicate with them on a support chat-group. If you need more, you can have Zoom sessions. But we only speak with them now if one of the devs finds something that doesn't look right. We haven't spoken to them in a long time.

Which solution did I use previously and why did I switch?

Snyk replaced some potential candidates. We had some people looking at maybe using CoreOS Clair and there were some discussions about what we could use to scan our repository. But we didn't have anything officially in place. In fact, Snyk was one of the first solutions that I put in place as a paid solution for the security of our code.

Security is something that is quite important for us. We take security seriously and it's something that we baked in from the early stages. We try to shift it as far left as possible. Snyk is a result of our organization's approach towards security, rather than vice-versa. It's playing its role alongside our security needs.

How was the initial setup?

In our organization, I ask that things be done and people are doing them, so I wasn't directly involved in the setup. But the installation seemed to be quite straightforward. I don't get pushback from the dev community. My background is more infrastructure, I'm not a developer, so I can't comment how easy it is to bring everything together. But when I worked with my devs, when we migrated from Concourse to Jenkins, it wasn't such a huge undertaking and it didn't cause us too many headaches.

In terms of developer adoption, they have to use it because we asked them to use it. And once it's part of the pipeline; everything that they push through the pipeline goes through Snyk. It was a company decision to go that way.

The initial rollout took about one week. Most of the stuff was already in place. We just migrated from one pipeline provider to another. It was quite straightforward.

We have a bit of a hybrid approach. Some of it was in the cloud, and we haven't touched that. The integration of the container bit, the CLI integration is done on our cloud and it's something we maintain. We tried to use Snyk's recommendations. It has an API that you can call use to run some scans, but their full-feature recommended solution is to use the CLI, using your own instance of Snyk. So we have a container that's running Snyk, and whenever we run the scans we just call on that.

The deployment involved one or two people internally. When it was just GitHub, it was me and one developer. And when it came to infrastructure, it was me with an infra guy. It depends on the level of expertise that you have in-house and how comfortable people are with similar solutions. At the end of the day, to roll up a container image and pull that into your pipeline is quite straightforward. It's not difficult.

We don't do that much maintenance on Snyk. It's integrated. It's running in the background. We only touch it when we need to touch it. It's not like we need dedicated resources for that.

Between 50 and 70 people are using Snyk at a given time in our organization. Most of them are developers. We might have some QAs who look at something.

What was our ROI?

It hits ROI for us very well in a couple of areas that we want to address: to ensure that we don't have surprises when it comes to vulnerabilities on our dependencies — libraries and images. And from a compliance point of view, we don't want to be in a situation where we're forced to publish code because someone has decided to use libraries that would force us to either publish everything under GPL or put us in a situation where licenses are not compatible and we would have to redo part of the code.

The ROI is one of those things that is difficult to quantify. It's not something where you can say how much money you have saved. But looking at overall cost versus the benefit, it's worth the money.

Time-to-value is a difficult topic because the way that I see it, Snyk is a preventative measure. It's similar to insurance. How much money are you prepared to spend to address a potential risk? By having a solution like Snyk in place, you prevent your company from being an easy target and being exposed. It's not something you can easily quantify, but Snyk falls under the cost of doing business. You want to have something in there because the overall cost and the overall problems will be a lot greater.

What's my experience with pricing, setup cost, and licensing?

Pricing and licensing of Snyk is okay. Their model is based on the number of committers of your source code, which can be a little bit false at times. It can be false because we have some QAs and some BAs, for example, who sometimes go in and add comments. They're not writing code, but they're flagged as committers of the code. That can cause some misunderstanding but we discussed this Snyk and explained the situation. They were quite okay with that. So although the number of people they see in Snyk is slightly higher, they're not holding us with our backs to the wall, saying, "Hey, you're over your license."

The only cost is whatever you run on your cloud. If you deploy the CLI integration and you run Snyk you need to take into account the cost, but it's not huge.

Which other solutions did I evaluate?

There are a number of other solutions out there that you can use. We looked at Black Duck from Synopsys and CoreOS Clair for containers. I had a bit of a look at WhiteSource. Because we're using open source software, a lot of our devs like the open source ethos. They had different suggestions so we looked at a number of potential use case scenarios. These days, for example, GitHub also allows you to scan your reports for dependencies and vulnerabilities. AWS also has the ability to scan your base images. You can validate different things at different stages. But the main one for moving the security to the left is Snyk.

In terms of the comprehensiveness and accuracy of Snyk's vulnerability database, I looked at that in the past. When I picked Snyk as a solution and was looking at Black Duck and other companies, I knew Snyk had its own database and was doing quite a lot of research in that area. To me it seems to be quite good compared to other solutions, like GitHub or Amazon. I get more out of Snyk. Snyk picks up more, highlights more, than other solutions I've seen.

Both Black Duck and WhiteSource are more established companies but they're probably more expensive. I haven't looked at the overall costs, but as you throw more into them they tend to be more expensive. Snyk meets our requirements.

What other advice do I have?

If your company develops software, and if you are an open source consumer, you need to have something in place. Do your research and find the best solution. For us, Snyk worked. I am involved in a security working group with my counterparts at our investors. We discussed what we're doing and what we are using and I discussed Snyk there. I discussed it with a couple of companies in particular and shared ideas and I recommended that they have a look at Snyk. Snyk is open source. You can take it for a ride and see if you like it. Once you're happy with it, you can move forward.

The biggest lesson I've learned from using Snyk is that it brings in a little bit of discipline in terms of what people can and cannot use. It also highlights the importance of security. It also adds a little bit of structure by surfacing potential issues. That's one of the most important factors. And having something like Snyk means you can validate and you can demonstrate, when meeting your clients and your investors, that you are meeting security needs and concerns.

In terms of the time it takes for developers to find fixed vulnerabilities, it depends on the type of issue. In some cases, for example, if there is an upgrade and there is a new version of the library, Snyk does make recommendations. If Snyk can do something for you it will do it. It can automatically generate a pull request so you can do a library upgrade. If there is something quite straightforward regarding licensing, they'll highlight that for you. But other issues are a little bit more complex. If it's a container image, for example, and there's no immediate image upgrade, maybe you want to do something like upgrade a library within the image. Some things are quite straightforward, and if Snyk can, it recommends it, and it's pretty easy, pretty straightforward. For other situations it will say you can manually upgrade this, but you'll have to do that process on your own.

Snyk's actionable advice when it comes to container vulnerabilities is aligned with the rest of the solution. We were one of the early users of containers. We have had Snyk in place for nearly two years, so when we started, containers were something very new for them. It's definitely better than other solutions which are free. Can it be better? Yes. As always, things can always be improved, but it's more or less on par with what we have on the regular dependency checks that we have on normal libraries as part of the source code.

If you look purely at the source code, we can do it with a SaaS application. You link your GitHub or your code repository with Snyk and, as you commit code, Snyk scans and reports. For containers, we tend to use the integration part of the CI/CD pipeline as well. All the images are passed through and we're using CLI commands to run this. This requires a little bit of extra setup, but once you put it in place it tends to be quite straightforward and doesn't require any additional work. As for allowing developers to own security for the applications and the containers they run in in the cloud, to be honest with you, in a lot of cases, their main focus is on developing the app. The scanning is more on the infra side. When it comes to containers and streamlining the application installation, that usually falls on the infra. They stay on top of that task. We have it integrated and we keep an eye out in case something has been plugged up. I just ask them to make sure it's addressed as soon as possible.

We're using Qualys to do external scans and external assessments. We also do penetration testing. But at the end of the day, you have to look at what you want from a tool. Maybe there are other solutions out there that claim to do a lot more. I'm sure that there are other vendors that can potentially give you a more integrated and better view, but they come with additional costs and additional complications. It all depends on what you want to do and how you want to achieve that. For us, the purpose of Snyk was to look at the vulnerabilities in the code or Docker container images, and to address the licensing aspect. 

Some companies go with individual solutions for every single part. For example, they use Clair to scan just the containers and something else to scan just the code. They have linting tools and other things. We're not just using Snyk. For example, we also have linting tools for code quality. This is not something that Snyk is doing. We're trying to use what is suitable for us.

Disclosure: IT Central Station contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.
Cameron Gagnon
Security Software Engineer at a tech company with 10,001+ employees
Real User
Top 10
Gives us a uniform way to access vulnerability information across a wide range of projects, teams, and structures

Pros and Cons

  • "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."
  • "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... 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."

What is our primary use case?

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.

How has it helped my organization?

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.

What is most valuable?

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.

What needs improvement?

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.

For how long have I used the solution?

I have been using Snyk for about a year.

What do I think about the stability of the solution?

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.

What do I think about the scalability of the solution?

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.

How are customer service and technical support?

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.

Which solution did I use previously and why did I switch?

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.

How was the initial setup?

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.

What about the implementation team?

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

What was our ROI?

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.

Which other solutions did I evaluate?

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.

What other advice do I have?

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.

Which deployment model are you using for this solution?

On-premises
Disclosure: IT Central Station contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.
Learn what your peers think about Snyk. Get advice and tips from experienced pros sharing their opinions. Updated: September 2021.
541,708 professionals have used our research since 2012.
RD
VP of Engineering at a tech vendor with 11-50 employees
Real User
Top 5
Scans our thousands of dependencies every time we build and rechecks them daily, making us aware of what's going on

Pros and Cons

  • "We're loving some of the Kubernetes integration as well. That's really quite cool. It's still in the early days of our use of it, but it looks really exciting. In the Kubernetes world, it's very good at reporting on the areas around the configuration of your platform, rather than the things that you've pulled in. There's some good advice there that allows you to prioritize whether something is important or just worrying. That's very helpful."
  • "There is always more work to do around managing the volume of information when you've got thousands of vulnerabilities. Trying to get those down to zero is virtually impossible, either through ignoring them all or through fixing them. That filtering or information management is always going to be something that can be improved."

What is our primary use case?

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

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

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

How has it helped my organization?

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

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

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

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

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

What is most valuable?

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

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

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

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

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

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

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

What needs improvement?

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

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

For how long have I used the solution?

We've been using Snyk for about 18 months.

What do I think about the stability of the solution?

The stability is pretty good.

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

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

What do I think about the scalability of the solution?

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

How are customer service and technical support?

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

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

Which solution did I use previously and why did I switch?

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

How was the initial setup?

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

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

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

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

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

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

What was our ROI?

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

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

What's my experience with pricing, setup cost, and licensing?

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

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

Which other solutions did I evaluate?

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

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

What other advice do I have?

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

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

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

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

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

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

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

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

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

Disclosure: IT Central Station contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.
Sean McElroy
CISO at a tech vendor with 51-200 employees
Real User
Top 5Leaderboard
Provides fantastic visibility into vulnerabilities and where they come from

Pros and Cons

  • "From the software composition analysis perspective, it first makes sure that we understand what is happening from a third-party perspective for the particular product that we use. This is very difficult when you are building software and incorporating dependencies from other libraries, because those dependencies have dependencies and that chain of dependencies can go pretty deep. There could be a vulnerability in something that is seven layers deep, and it would be very difficult to understand that is even affecting us. Therefore, Snyk provides fantastic visibility to know, "Yes, we have a problem. Here is where it ultimately comes from." It may not be with what we're incorporating, but something much deeper than that."
  • "It lists projects. So, if you have a number of microservices in an enterprise, then you could have pages of findings. Developers will then spend zero time going through the pages of reports to figure out, "Is there something I need to fix?" While it may make sense to list all the projects and issues in these very long lists for completeness, Snyk could do a better job of bubbling up and grouping items, e.g., a higher level dashboard that draws attention to things that are new, the highest priority things, or things trending in the wrong direction. That would make it a lot easier. They don't quite have that yet in container security."

What is our primary use case?

We use it to do software composition analysis. It analyzes the third-party libraries that we bring into our own code. It keeps up if there is a vulnerability in something that we've incorporated, then tells us if that has happened. We can then track that and take appropriate action, like updating that library or putting a patch in place to mitigate it. 

They have also added some additional products that we use: One of which is container security. That product is one that analyzes our microservices containers and provides them with a security assessment, so we are essentially following best practices.

How has it helped my organization?

From the software composition analysis perspective, it first makes sure that we understand what is happening from a third-party perspective for the particular product that we use. This is very difficult when you are building software and incorporating dependencies from other libraries, because those dependencies have dependencies and that chain of dependencies can go pretty deep. There could be a vulnerability in something that is seven layers deep, and it would be very difficult to understand that is even affecting us. Therefore, Snyk provides fantastic visibility to know, "Yes, we have a problem. Here is where it ultimately comes from." It may not be with what we're incorporating, but something much deeper than that.

The second thing that is critical in some cases, and Snyk provides as a value, is their guidance. Somewhere along the chain it figures the vulnerabilities out, then Snyk provides an update. So, what you need to do is go update to the latest version of that library, which is easy. However, sometimes it's not that easy, then Snyk has great guidance where you could go to manually patch it yourself, and they've made that a pretty seamless process. You can run a command with this new tooling, and it will go fix the underlying vulnerability for you. That is unusual. I have not seen that in other products.

It has improved the overall security of our applications by removing vulnerabilities and things that we are incorporating into our product. It ultimately identifies vulnerabilities in our product as well. It helps us when we do other types of testing of our applications, as we're not finding issues by something we had incorporated. Therefore, it reduces the vulnerabilities in our application.

What is most valuable?

For a developer, the ease of use is probably an eight out of 10. It is pretty easy to use. There is some documentation to familiarize themselves with the solution, because there are definitely steps that they have to take and understand. However, they are not hard and documented pretty well.

We have integrated Snyk into our SDE. We have a CI/CD pipeline that builds software, so it's part of that process that we will automatically run. We use Jenkins as our pipeline build tool, and that's what we have integrated. It is pretty straightforward. Snyk has a plugin that works out-of-the-box with Jenkins which makes it very easy to install.

Snyk's vulnerability database is excellent, in terms of comprehensiveness and accuracy. I would rate it a nine or 10 (out of 10). They have a proprietary database that is very useful. They are also very open to adding additional packages that we use, which might be not widely used across their customer base.

What needs improvement?

Snyk's ability to help developers find and fix vulnerabilities quickly is pretty good. From a one to 10, it is probably a six or seven. The reason is because they make it very clear how to take the steps, but it's not necessarily in front of the developers. For instance, my role here is security, so I go and look at it all the time to see what is happening. The developer is checking code, then their analysis runs in the pipeline and they have moved on. Therefore, the developers don't necessarily get real-time feedback and take action until someone else reviews it, like me, to know if there is a problem that they need to go address.

Snyk does a good job finding applications, but that is not in front of the developers. We are still spending time to make it a priority for them. So, it's not really saving time, e.g., the developers are catching something before it goes into Snyk's pipeline.

A criticism I would have of the product is it's very hierarchical. I would rate the container security feature as a seven or eight (out of 10). It lists projects. So, if you have a number of microservices in an enterprise, then you could have pages of findings. Developers will then spend zero time going through the pages of reports to figure out, "Is there something I need to fix?" While it may make sense to list all the projects and issues in these very long lists for completeness, Snyk could do a better job of bubbling up and grouping items, e.g., a higher level dashboard that draws attention to things that are new, the highest priority things, or things trending in the wrong direction. That would make it a lot easier. They don't quite have that yet in container security.

One area that I would love to see more coverage of is .NET. We primarily use JavaScript and TypeScript, and Snyk does a great job with those. One of the things that we are doing as a microservices developer is we want to be able to develop in any language that our developers want, which is a unique problem for a tool like this because they specialize. As we grow, we see interest in Python, and while Snyk has some Python coverage that is pretty good, it is not as mature. For other languages, while it's present, it is also not very mature yet. This is an area for improvement because there was a very straightforward way that they integrated everything for Node.js. However, as other languages like Rust and .NET gain popularity, we may just have one very critical service in 200 that uses something else, and I would like to see this same level of attestation across them.

For how long have I used the solution?

Since about 2016.

What do I think about the stability of the solution?

The stability is very good. We have not run into issues that have been large-scale outages. It is not a real-time solution. So, even if we had an outage of a day, it wouldn't really affect the way we operate. It is an asynchronous thing behind the scenes.

It requires about 200 hours a year of time to maintain it. By maintain it, I mean just go in, use the reports, validate them, and kind of manage them. There is a resource cost to us to operationalize it, but it's about 200 hours.

What do I think about the scalability of the solution?

It is very capable at what it does. It has a pretty good completeness of vision and its execution is good.

There are certain tools which Snyk has that developers can use. Those have a very low level of adoption. It was adopted into our pipeline, so we get things there and report them back to development. However, development largely has not adopted it themselves. We have push the findings to them.

Most of the users are a mix between security and operational folks as well as some development managers. Unfortunately, the developers themselves don't necessarily adopt Snyk on their own. Therefore, it's really more those who are running the pipeline, like our operations team, my security team, and the managers who are receiving the reports if there's something in Snyk or there is actually an issue.

We are using all the products they provide today. We use it for everything that we develop, so I don't know that there is a whole lot more that we can use unless they provide a further offering.

How are customer service and technical support?

Snyk's technical support is middle of the road. I would rate it a six (out of 10). They are friendly and try to be helpful. Some of the times that I have actually had to reach out to them, it takes a lot of back and forth to get issues understood and resolved. They do try, but it can be a lengthy process.

Which solution did I use previously and why did I switch?

We started using this solution at this company when the company was started, so it's the only thing we have ever used.

In the past, I have used Veracode, WhiteHat Security, and Black Duck by Synopsys for some of their features.

How was the initial setup?

The initial setup was straightforward. Snyk was brought in at a time when there were less than five employees, and they set it up that day. We just needed one person to deploy it, and it took them a day. It was easy and so straightforward that it didn't require a project.

What was our ROI?

If I didn't see ROI, I would move somewhere else. I would probably go to a cheaper solution, but Snyk is definitely above that compliance level of value. It is really proactive, and that's where I would rather be from a security program perspective. So, I do get the value out of it.

Snyk finds problems that we may not have ever found otherwise, so it is a significant benefit for us. It reduced the amount of time by an FTE, which is about 2000 hours a year that we would spend in doing what Snyk does with its tool.

Over the course of a year, Snyk has reduced the amount of time it takes to fix problems by approximately 100 hours in our enterprise. It makes it very clear what the fix is. They provide very good remediation advice. 

The total time to value will depend on the company who implements it. For us, it was pretty short, probably two to three months. While it was very easy to set up, it takes a little while to really appreciate how its findings need to be addressed within the company. It forces you to develop some processes and feedback loops that you may not have had there before. So, it took us 90 days to fully appreciate the value and start remediating findings that were initially discovered.

What's my experience with pricing, setup cost, and licensing?

With Snyk, you get what you pay for. It is not a cheap solution, but you get a comprehensiveness and level of coverage that is very good. The dollars in the security budget only go so far. If I can maximize my value and be able to have some funds left over for other initiatives, I want to do that. That is what drives me to continue to say, "What's out there in the market? Snyk's expensive, but it's good. Is there something as good, but more affordable?" Ultimately, I find we could go cheaper, but we would lose the completeness of vision or scope. I am not willing to do that because Snyk does provide a pretty important benefit for us.

Snyk is a premium-priced product, so it's kind of expensive. The big con that I find frustrating is when a company charges extra for single sign-on (SSO) into their SaaS app. Snyk is one of the few that I'm willing to pay that add-on charge, but generally I disqualify products that charge an extra fee to do integrated authentication to our identity provider, like Okta or some other SSO. That is a big negative. We had to pay extra for that. That little annoyance aside, it is expensive. You get a lot out of it, but you're paying for that premium.

Which other solutions did I evaluate?

I have not seen much in the way of false positives from Snyk. I have used a lot of software analysis tools and some are pretty bad, but Snyk is fantastic. I struggle to remember a time where Snyk found an issue that wasn't a true issue. It may have been very thorny to understand and resolve, but I have always found it to be accurate.

I have looked at other solutions, but Snyk continues to win out in evaluations. I also looked at WhiteHat Security and Black Duck by Synopsys. 

We do use a product with WhiteHat Security, which is now owned by NTT Data, for SAST, DAST and manual pentesting. I have also used other independent contractors for some of that. I was looking at Synopsys and a separate product called Coverity for SAST in addition to what we use with Snyk. Separate from that, we do use SAST and DAST in interactive and mobile testing.

Snyk doesn't do SAST or DAST; they do software composition analysis. These are really separate offerings that don't really cross over. I would not go to Snyk for SAST and DAST, so I wouldn't make any competitive changes with my other vendors that are providing that solution.

There are a few other vendors who provide overlapping coverage for container security. However, for software composition analysis, we only use Snyk, so the solution is very important for us.

What other advice do I have?

If you're going to be doing any sort of software development that involves open source software, like many people do, many people have a blind spot or don't have a tool like this to even understand the risk that they take by pulling in an open source. It's not to say open source is bad, it just has a new threat surface that you have to monitor. We get a lot of benefit out of monitoring it, so I think ultimately we see problems others don't and have the opportunity to fix them. Therefore, there is a good chance that we will have fewer issues, like unauthorized data access, where they are sort of significant events because we have the visibility and the means to rectify them.

Snyk's actionable advice about container vulnerabilities is pretty good. I would rate it a six (out of 10). It's a newer offering for them, so it doesn't have the completeness of vision that their software composition analysis has, but it still appears to be accurate. It's a different type of product. They haven't packaged it to be very actionable, e.g., just do this one thing or here is the next step to fix this. It is a bit more abstract and has an explainer to it. You have to sort of distill that into what you need to do, but it still seems accurate. It is a little bit more to wrap your head around than how easy they have made the software composition product.

If you are looking for a software composition analysis product that provides remediation advice and you can't act on the details it's going to give you, you might be just as good dealing with a little bit less full featured product. However, if you want to be proactive as well as have the capability and technical resources that can move on the recommendations that Snyk makes, then you can realize a significant value out of this product. Thus, if you are at the level of maturity that can appreciate what this product can provide, it is a great value.

I would rate this solution a nine (out of 10).

Disclosure: IT Central Station contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.
SK
Sr. Security Engineer at a tech vendor with 201-500 employees
Real User
Top 10
Container security allows developers to own security for the applications and containers they run in the cloud

Pros and Cons

  • "The most valuable features include enriched information around the vulnerabilities for better triaging, in terms of the vulnerability layer origin and vulnerability tree."
  • "We've also had technical issues with blocking newly introduced vulnerabilities in PRs and that was creating a lot of extra work for developers in trying to close and reopen the PR to get rid of some areas. We ended up having to disable that feature altogether because it wasn't really working for us and it was actually slowing down developer velocity."

What is our primary use case?

We enable Snyk on all of our repos to do continuous scanning for open-source dependency, vulnerabilities, and for license compliance. We also do some infrastructure and code scanning for Kubernetes and our Docker containers.

Snyk integrates with GitHub which lets us monitor all private and public repositories in our organization and it enables developers to easily find and fix up source dependency vulnerabilities, container-image vulnerabilities, and ensures licenses are compliant with our company policies.

How has it helped my organization?

It's given us more insight in terms of what our risk is to open-source dependencies and helps us reduce the quantity of open-source dependency vulnerabilities that we have within our code base.

Snyk has absolutely reduced the amount of time it takes to find problems, with its automated PR. The challenge, initially, was that there were a lot of false positives with the previous product that we had. We had to eliminate the noise ratio. Snyk is accurately detecting the vulnerabilities and pinpointing the sources of where they exist. In terms of discovery and accuracy, it has reduced the time involved by 50 percent.

It's also giving our developers informed insights to take action on where vulnerabilities are introduced into the code. Depending on how you define "productivity" you could say it's reducing their productivity because it's showing that they have issues with their code and that they have to go back and fix it. It might not necessarily be increasing productivity, but in the sense of not incurring tech or security debt, it's improving those aspects. Overall, that should lead to an improvement in productivity.

What is most valuable?

The most valuable features include 

  • detection 
  • the reporting aspect where we can get an overall glance at vulnerabilities across all of our organizational repos 
  • the enriched information around the vulnerabilities for better triaging, in terms of the vulnerability layer origin and vulnerability tree.

Its actionable advice about container vulnerabilities is good. The container security feature definitely allows developers to own security for the applications and the containers they run in the cloud. They have the ability to go in and review the vulnerabilities and to remediate as needed. Currently, it's only scanning. We're not doing any type of blocking. We're putting more of the onus on the developers and owners to go and fix the vulnerabilities. They're bound to internal SLAs.

The solution’s vulnerability database is very comprehensive and accurate. One thing we were looking at is the Exploit Maturity, which is a relatively new feature. We haven't really gotten back to tune that, but it is something we were looking at so we can know the exploit maturity, based on these vulnerabilities. That is super-valuable in understanding what our true risk is, based on the severity. If something is out in the wild and actively being exploited, that definitely bumps the priority in terms of what we're trying to remediate. So it helps with risk-prioritization based on the Exploit Maturity.

What needs improvement?

There is room for improvement in the licensing-compliance aspect. There have been some improvements with it, but we create severities based on the license type and, in some cases, there might be an exception. For example, if we actually own the license for something, we'd want to be able to allow based on that. That specific license type might exist in different repos, but it could be that in a specific repo we might own the license for it, in which case we wouldn't be able to say this one is accepted. That would be an area of improvement for legal, specifically.

We've also had technical issues with blocking newly introduced vulnerabilities in PRs and that was creating a lot of extra work for developers in trying to close and reopen the PR to get rid of some areas. We ended up having to disable that feature altogether because it wasn't really working for us and it was actually slowing down developer velocity. To be honest, that's where it's at today. We haven't been using it much in that way, to block anything. We work in a non-blocking fashion and we give the ownership to the developers. And then we monitor and alert based on what we have and what we've discovered.

For how long have I used the solution?

We have been using Snyk for about a year.

What do I think about the stability of the solution?

I haven't noticed any stability issues.

There have definitely some been some software flaws, bugs, of course, but that just comes with the nature of software in general. But the customer support team has been very responsive when we actually need something. They've been reaching out to us, they've gotten engineers on the calls to talk through our problems. It's been good enough in that way.

What do I think about the scalability of the solution?

It's scalable.

Which solution did I use previously and why did I switch?

We previously used a solution called Black Duck and the reason we switched was because there were a lot of false positives. There was a lot of noise and it wasn't useful to developers.

As my organization's security program continued to mature, our team was looking for ways to effectively build a more secure product. One area of risk we wanted to address was the use of open-source software. Although open-source software has many benefits, it includes vulnerabilities that, if not managed properly, could expose us to potential breaches. To address this risk, we purchased Snyk.

Snyk's extensive vulnerability database helps us stay on top of those occurrences as they surface. In addition, we use Snyk to help ensure compliance with open-source security policies. We replaced Black Duck with Snyk as a more developer-friendly solution to help us govern our security and license compliance as well as to reduce false positive findings.

How was the initial setup?

The initial setup was pretty straightforward. You just sign up for an account and then you work with the sales engineers, the technical engineers, to enable it across your organization. Then you just import all the repos you want to start scanning on and that's pretty much it. Out-of-the-box it works.

The deployment took a day or two days. It wasn't very intensive. The main thing was the internal process of getting buy-in from leadership and getting things put into place.

In terms of our deployment strategy, we ran it against the master branch of select repositories. We picked a handful of repos that we wanted to start scanning against. We disabled tests on pull requests temporarily and we enabled SSO so people could log in via Okta to start reviewing reports. Everybody had access to it in R&D. Everybody then had the ability to start opening Snyk pull requests for vulnerabilities that were discovered. Then we established how we would treat the information coming from Snyk, including SLAs tied to the severity, etc.

We told people to expect that Snyk would be enabled on the master branches of all our repositories and that it continuously scans the dependency files such as the package.json, requirements.txt, Gemfile.lock, etc., on a scheduled basis. If new vulnerabilities are discovered, we told them findings would be generated and could be viewed on a new dashboard and developers could customize their notification settings in Snyk's console. For each pull request we test for new vulnerabilities.

The rollout plan was working with two squads per month to begin the implementation. The security team would embed with them to understand how they were using the tool and learn about their process — if things weren't working, or were working and they liked it. We would gradually roll it out to the next squad and the next squad. We have 600 engineers here, so we didn't want to just flip the switch and turn it on all at once. We worked with teams individually to understand their workflows, and to see if they disliked it or liked it.

We were also tuning the SLAs for remediation for vulnerabilities. We didn't want to be too aggressive in what we were asking from the developers around the SLA for remediation. And because we were putting the SLAs in place, we were blocking other product-feature work that was coming down the pipeline. We're also an Agile development shop. Customer security usually comes after, so we were dealing with those trade-offs.

We had a few bumps along the way with enabling newly introduced vulnerabilities on an open PR. We pulled back on the entire project and just left it running. The security team really hasn't had a chance to go back and tune it.

Developer adoption of the solution has been low in our company. Management isn't really enforcing the use of the tool yet. There have been more pressing issues. So the low adoption is more more the result of an internal process than it is because of actual value from the product. They do find a lot of value with it when they start using it properly. Overall, we've had positive feedback from developers.

What was our ROI?

The time-to-value of Snyk is still still a work-in-progress in our company.

What other advice do I have?

I would advise that there be communication within the organization about how the tool is going to be used, what it's going to be used for, and for establishing and communicating a rollout plan. The steps that I listed previously about our rollout plan were well received and followed. With larger organizations, that's probably the best path forward: limiting the number of people using the tool, up front, to work out workflows, and then gradually rolling it out to the wider audience until you get full coverage.

We understood that the full implementation of Snyk into the development and operations lifecycle introduced a change. We also understood that fixing all the existing vulnerabilities immediately would not be a viable strategy. So we started with a partial implementation to gain insight from developers on the preferred ways of working, which would help us manage business priorities and roadmap initiatives. From there, we established a policy on how we retreat information coming from Snyk, including SLAs tied to the severity of findings. 

After that, depending on the size of your organization, the suggestion would be to work with select teams. For us, it was two teams per month, focusing on the process of remediating existing vulnerabilities until we worked with all teams across the organization. 

In addition, Snyk offered free onsite training if requested, so take advantage of that.

Everything that the product promises it will do, it's been doing that for us. It's good. It's serving its purpose. We have definitely had some technical issues with it. We really haven't had a lot of time to spend with it and to focus on tuning it since we procured the solution, and to actively get it into our development pipeline. But from what it promises, I would rate it at eight out of ten.

Disclosure: IT Central Station contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.
RA
Application Security Engineer at a tech services company with 501-1,000 employees
Real User
Top 10
Helps us to prioritize fixes and suggests version upgrades, saving us significant time

Pros and Cons

  • "The most valuable feature is that they add a lot of their own information to the vulnerabilities. They describe vulnerabilities and suggest their own mitigations or version upgrades. The information was the winning factor when we compared Snyk to others. This is what gave it more impact."
  • "The solution's vulnerability database, in terms of comprehensiveness and accuracy, is very high-level. As far as I know, it's the best among their competitors."
  • "We tried to integrate it into our software development environment but it went really badly. It took a lot of time and prevented the developers from using the IDE. Eventually, we didn't use it in the development area... I would like to see better integrations to help the developers get along better with the tool. And the plugin for the IDE is not so good. This is something we would like to have..."

What is our primary use case?

We have a lot of code and a lot of microservices and we're using Snyk to test our third-party libraries, all the external dependencies that our code uses, to see if there are any vulnerabilities in the versions we use.

We use their SaaS dashboard, but we do have some internal integrations that are on-prem.

We scan our code and we go through the results on the dashboard and then we ask the teams to upgrade their libraries to mitigate vulnerabilities.

How has it helped my organization?

We feel more secure because we do have a way to measure the security and the risk factors of projects. We're able to create action items for the developers to fix. We have the feeling that we can worry less about these kinds of vulnerabilities, which are very critical vulnerabilities, in all the third-party libraries.

The solution has reduced the amount of time it takes to find problems, for sure. Without it, I would have to do things manually: Go to a project, get the list of libraries and the versions, and then search manually, one by one, in Google. It saves a lot of time. It's hard to estimate how much time it saves, but it must be days of work.

It helps us spend less time securing applications and that way it increases productivity. It saves a lot of time in looking for vulnerabilities in our projects. And, of course, it's much more efficient and quick with Snyk. It's saving us a lot of working days, maybe even weeks.

Snyk also helps us to prioritize things, what we need to deal with. For example, it tells us if there is an available online exploit for the vulnerability in a given library. That way, we know that we will want to address this issue first, because maybe some hacker could use the available exploit on us. It also has a pretty new feature, which is Snyk's own risk score from zero to 1,000, and that has also helped to prioritize. Another new feature we haven't tested yet is to see if a function is really in use in the code, which will also help to prioritize. And, of course, the suggested version to upgrade to is really important information for us.

What is most valuable?

The most valuable feature is that they add a lot of their own information to the vulnerabilities. They describe vulnerabilities and suggest their own mitigations or version upgrades. The information was the winning factor when we compared Snyk to others. This is what gave it more impact.

For us, in the security team, it's pretty easy to use it to look for issues. If we want to look at a specific project, which may be external or more important or it may be more sensitive, we just go to the Snyk dashboard, look for the project, and directly get a list of all the issues, by severity. It also shows if there is a fix available. The filter is pretty good and we are able to get action items pretty immediately for the developers.

The solution's vulnerability database, in terms of comprehensiveness and accuracy, is very high-level. As far as I know, it's the best among their competitors.

Also, I don't think there are false positives. Even if there is a vulnerable library that is in use, but maybe we're not using the function itself, it's not telling us that we do use that function. There isn't much of a false positive issue.

What needs improvement?

We tried to integrate it into our software development environment but it went really badly. It took a lot of time and prevented the developers from using the IDE. Eventually, we didn't use it in the development area.

If the plugin for our IDE worked for us, it might help developers find and fix vulnerabilities quickly. But because it's hard to get the developers to use the tool itself, the cloud tool, it's more that we in the security team find the issues and give them to them.

I would like to see better integrations to help the developers get along better with the tool. And the plugin for the IDE is not so good. This is something we would like to have, but currently we can't use it.

Also, the API could be better by enabling us to get more useful information through it, or do more actions from the API.

Another disadvantage is that a scan during CI is pretty slow. It almost doubles our build time.

For how long have I used the solution?

I have been using Snyk for about two years.

What do I think about the stability of the solution?

I have never experienced any instability in the solution. It's pretty good.

How are customer service and technical support?

Their technical support is pretty good. We have a customer success manager. His name is Eliran and he's really nice. He helps us sometimes with actual support, but at other times he helps us with figuring out how to work with Snyk, or how to continue and expand with it.

Which solution did I use previously and why did I switch?

Before Snyk we used one of its competitors, WhiteSource. We switched to Snyk because we were near the end of our WhiteSource license and we wanted to look at other options. We looked at the competitors and we saw that Snyk has a lot more valuable information on issues, such as exploitability online, and the suggested fixes for libraries, and there were more features. All of this information is very valuable for us, and WhiteSource was lacking it.

How was the initial setup?

The initial setup wasn't too complex. They have good documentation, and it's pretty easy. Because our code repository and ticketing system are internal, we had to set up some Dockers to help us with that, but that also wasn't too hard.

The first deployment, until we started scanning the first project, took less than a week. To get it fully working as we expected, exactly how we wanted it, took some more time. That took some months. But the initial setup was really just a few days.

The implementation strategy was that we first wanted to scan the integration with our internal Bitbucket, the code repository, and get Snyk to scan all of the repositories on a daily basis. We had some struggles at first. We wanted to add the developers as users, so they could use the dashboard, but that didn't work so well. So we used a JIRA integration for ticketing and wrote some scripts that use the API to get some information and create tables with action items. Also, we wanted to add it to our CI so that every time a project was being built, a scan would start and the developer would get the information at that moment.

Right now, we're writing an automation to automatically open JIRA tickets with information from Snyk, for the teams. Hopefully, that will make my job more efficient, and even decrease the amount of work I need to do.

If maintenance is required it's on me, but I really only update our Dockers from time to time. There isn't too much maintenance.

What about the implementation team?

I did it almost all by myself, but we did use Snyk from time to time. I would send them some logs if we had a problem and they would review then and respond with an answer in a few days.

What was our ROI?

We don't have numbers that say we saved this or that amount because of Snyk, but we have seen ROI. The time I would spend on those kinds of vulnerabilities without Snyk would cost more than what it costs us.

The time to value was pretty much from the beginning; maybe one month or two.

Which other solutions did I evaluate?

We also looked at Black Duck and SourceClear. The difference between them and Snyk, as with WhiteSource, was the information. The Snyk dashboard was also more user-friendly and more informative. Back then, it looked more user-friendly for the developers, to get them using it. That didn't happen ultimately for us, but it did look that way at the beginning. Their added information was the main trigger.

What other advice do I have?

If you're on-cloud it's pretty easy. If you're on-prem I'd suggest you look carefully at how the integrations should be. I spent some time configuring the Docker because I didn't have the right information, from our side. It would be good to know better the infrastructure and how the source code or ticketing system works before starting to implement the internal Dockers. But if it's on-cloud and you are only using the SaaS dashboard, it's pretty easy.

It is easy to use, but it's hard to get the developers to use it. That part is not too easy. Our developers are not that into it. We, the security team, have to do a lot of manual work ourselves. We have to do a lot of triaging ourselves and then ask the developer teams to take action. I don't think the developer reluctance is something in the tool; I don't think it's the tool's fault. The subject itself is not that appealing to developers and they don't like to take care of security much. It's hard to get them to use it.

Only our security team of three people uses the Snyk dashboard itself. Unfortunately, no developers are using it. I use it on a weekly basis. On the security side, the adoption is high. And the developers always follow my instructions based on the Snyk results that I send to them. If you include the developers who are using my recommendations, then there are dozens of developers "using" it.

I don't think it has reduced the amount of time it takes to fix problems, because ultimately it just tells us to upgrade to a specific version. If we got this information manually, without Snyk, we would still just need to upgrade to that specific version. It's still on the developer side to make the fix. I don't think Snyk is important for that part.

The lack of SAST and DAST in the solution didn't affect our decision to go with Snyk because we see the solution as another aspect of security. I don't know if they should go to SAST or DAST because they are really good at what they do. The product is very good for this kind of security. 

Overall, it's hard to say if it has greatly helped our security. It's hard to measure it. I can't say that we had an actual exploitable section in our site that was fixed with Snyk. It's just that we feel way more secure now. The added information they provide is very valuable and helps us prioritize. Prioritization is the most valuable thing we have gotten from Snyk.

Disclosure: IT Central Station contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.
JB
Security Analyst at a tech vendor with 201-500 employees
Real User
Top 10
It reports on all the vulnerabilities present in all our different packages

Pros and Cons

  • "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."
  • "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."

What is our primary use case?

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.

How has it helped my organization?

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

What is most valuable?

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.

What needs improvement?

• 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 how long have I used the solution?

For two years.

What do I think about the stability of the solution?

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

What do I think about the scalability of the solution?

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.

How are customer service and technical support?

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. 

Which solution did I use previously and why did I switch?

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.

How was the initial setup?

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

What was our ROI?

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.

What other advice do I have?

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

Which deployment model are you using for this solution?

Public Cloud

If public cloud, private cloud, or hybrid cloud, which cloud provider do you use?

Other
Disclosure: IT Central Station contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.
CB
Senior Manager, Product & Application Security at a tech services company with 1,001-5,000 employees
Real User
Top 5
It's easy to find vulnerabilities, create a report, and use the data

Pros and Cons

  • "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."
  • "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."

What is our primary use case?

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.

How has it helped my organization?

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.

What is most valuable?

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.

What needs improvement?

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.

For how long have I used the solution?

A year.

What do I think about the stability of the solution?

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.

What do I think about the scalability of the solution?

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.

How are customer service and technical support?

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.

Which solution did I use previously and why did I switch?

Our company did not use anything before Snyk.

I have used Nexus IQ in another company.

How was the initial setup?

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.

What was our ROI?

We have not seen ROI yet.

What's my experience with pricing, setup cost, and licensing?

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

Which other solutions did I evaluate?

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.

What other advice do I have?

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

Disclosure: IT Central Station contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.
Buyer's Guide
Download our free Snyk Report and get advice and tips from experienced pros sharing their opinions.