Snyk Reviews

The primary use case is dependency vulnerability scanning and alerting.

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

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

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

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

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

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

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

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

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

Their API and UI are great.

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

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

Close to three years.

My impressions of the stability are very high.

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

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

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

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

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

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

Our initial deployment took less than a week.

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

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

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

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

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

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

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

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

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

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

They're always coming out with new stuff.

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

It is a source composition analysis tool that we use to perform vulnerability scanning for those vulnerabilities within open source libraries.

This is a SaaS solution.

It has improved our vulnerability rating and reduced our vulnerabilities through the tool during the time that we've had it. It's definitely made us more aware, as we have removed scoping for existing vulnerabilities and platforms since we rolled it out up until now.

We were aware of problems that were there, but we weren't looking for them until we had Snyk. It is definitely showing us things that we should have been concerned about, and we have found a lot of value in resolving those things since we've discovered them.

It's reduced the amount of active vulnerabilities in our applications, providing both a more stable and secure environment for us in the libraries that we develop. It has highlighted a number of things we weren't aware of in our applications and the reduction of those is definitely a benefit and value-add to our applications.

The general source composition analysis is the key to the piece. That is the feature to check our open source libraries for vulnerabilities and the primary feature that we use the tool for.

It is extremely easy to use and very simple to catch on for every team that we train on it. We generally have our development teams leverage the tool themselves. It's extremely easy to teach them how to use it and get them to onboard it.

From a speed perspective, we use Git repository. It was very easy to integrate into that platform.

The solution’s ability to help developers find and fix vulnerabilities quickly is very good and convenient. It provides the ability to easily work the platform into our existing repositories and leverage our repository. It also pulls notifications as a means for notifying developers of vulnerabilities within the projects that are developing.

The solution’s vulnerability database is very comprehensive and accurate.

There are some new features that we would like to see added, e.g., more visibility into library usage for the code. Something along the lines where it's doing the identification of where vulnerabilities are used, etc. This would cause them to stand out in the market as a much different platform.

We have been using Snyk for about a year.

It is very stable.

We use existing staff to maintain and operationalize it.

It is extremely easy to scale and hooks into all of our application repositories without any issues. We use the product extensively in the projects that we are currently running. We are using the product at close to 100 percent.

Developer-adoption of the solution has been good. It is one of the better tools in our application security library from an adoption perspective and needs of use. It has the most positive feedback out of all our solutions.

There are probably 50 users who are security/developers and development-focused security professionals.

The only technical support that we have received has been through our account team, and it's been fantastic. I haven't actually had to open any tickets or anything using the tool. The only time we've ever needed assistance was to open up a ticket for single sign-on configuration. It was extremely quick. They had a very easy, fast response for how to deliver it.

We previously used Black Duck. We switched to Snyk because of its better false positive ratings along with its ease of use, integration, and deployment.

The initial setup was straightforward. It was just extremely easy to integrate into our repositories, get the code scanning working, and add our projects into the application.

The deployment was quick. We had our first application in it within minutes.

Implementation strategy: We hooked up our applications and integrated them into the tool. Then, we started to address vulnerabilities as we saw fit from a risk perspective.

We have seen ROI with Snyk. It has showed us a lot of things that we were not privy to before. This has opened our eyes to a lot of very important things, e.g., vulnerabilities.

The solution has reduced the amount of time it takes to fix problems. It has done a great job explaining what the problem is and how to resolve it with remediation. It gives you a lot of details about versioning and such for the library. It is definitely helpful there.

The time-to-value of the solution in our company was almost immediate.

It's inexpensive and easy to license. It comes in standard package sizing, which is straightforward. This information is publicly found on their website.

We focused our evaluation specifically on Black Duck and Snyk, plus Veracode as a larger product offering.

The Snyk platform does everything we've expected it to do. It works much better than some of the competitors we looked at during our assessment.

If you're looking for a source composition analysis tool or a tool to monitor your open source security, then it's a fantastic solution.

SAST and DAST are very important functions. We have alternative options for those though. I wouldn't say the solution’s lack of SAST and DAST hurts or affects us. It would be nice if these were a platform or offering that they did have.

We don't use the solution’s Container security feature at the moment, but we are planning on using it.

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

I use Snyk to review my code. 

Snyk helps me pinpoint security errors in my code. 

Sometimes we have problems upgrading a library because it's too old. The only thing we can do is use another library. 

It is easy to scale Snyk once you install it, but it depends on your cloud service provider. Everything will scale smoothly if you have the correct cloud server settings. 

I rate Snyk support eight out of 10. 

Positive

Setting up Snyk is relatively complex if you're working with multiple developers who use different IDEs. It can be complicated if, for example, one developer uses Visual Studio and another developer uses a different editor. 

Snyk is cloud-based. We use Bamboo for CI/CD, and we had problems integrating Snyk with it. Ultimately, we got the two solutions to work together, but it was difficult.

I rate Snyk three out of 10 for affordability. The price is relatively high, but it's worth it. 

I rate Snyk seven out of 10. 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

We've been using Snyk for about 18 months.

The stability is pretty good.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

It helps find issues quickly because:

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

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

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

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

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

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

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

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

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

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

We have been using this product for five months.

The product is sometimes unstable.

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

We currently have 20 developers who use it.

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

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

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

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

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

We did not previously use another solution in this company.

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

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

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

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

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

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

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

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

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

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

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

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

Check the following before using Snyk:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

A year.

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

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

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

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

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

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

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

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

Our company did not use anything before Snyk.

I have used Nexus IQ in another company.

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

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

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

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

We have not seen ROI yet.

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

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

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

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

Snyk is used to manage open-source risks in security and licenses.

The most valuable feature of Snyk is the software composition analysis.

The reporting mechanism of Snyk could improve. The reporting mechanism is available only on the higher level of license. Adjusting the policy of the current setup of recording this report is something that can improve. For instance, if you have a certain license, you receive a rating, and the rating of this license remains the same for any use case. No matter if you are using it internally or using it externally, you cannot make the adjustment to your use case. It will always alert as a risky license. The areas of licenses in the reporting and adjustments can be improved.

Having bolting scans into a single solution can be useful, maybe snippet capabilities of reading the actual scan rather than reading the manifest can be very useful.

I have been using Snyk for several years.

The stability of Snyk is good.

Snyk is highly scalable. The only thing running on the customer side is a command-line interface(CLI). The entire results are been presented on a software as a service-based platform. It doesn't matter if I'm running 10 or 10,000 systems. It's scalable because Snyk has a supportive system, which is not the customer's system, it's Snyk's system.

I have not used the support from Snyk. However,  customers are sharing their experiences, and they have said the support is good.

The initial setup of Snyk needs their assistance and support. It's not a Windows application that you click next, but it's not rocket science. The implementation typically takes a few days to complete.

The company that purchases Snyk typically does the implementation. There are only a few people needed for the deployment of the solution.

Snyk allows developers and development managers to identify open-source vulnerabilities in every stage. As a result, the fix is much cheaper than identifying something on production. It's up to 100 times less expensive. If you fix a few bugs at an early stage, you cover all the license fees for the annual subscription of Snyk. There is a high return on investment potential.

The license model is based on the number of contributing developers. Snyk is expensive, for a startup company will most likely use the community edition, while larger companies will buy the licensed version. The price of Snyk is more than other SLA tools.

I rate Snyk an eight out of ten.

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. 

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.

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.

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.

We've been using Snyk for nearly two years.

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.

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.

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.

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.

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.

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.

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.

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.

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.