Snyk Reviews

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.

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.

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.

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.

Since about 2016.

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.

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.

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.

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.

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.

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.

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.

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.

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

Since some of our development is using open source packages, we need a way to identify the vulnerabilities before using those packages for development. Using Snyk, we can identify all the safe packages, which to use and which to not use, and create a safe repository for developers.

The goal is to catch the vulnerabilities early within the process and fix them before they get to the security review where they can cause deadlines to be pushed out to fix them.

We're using the cloud version.

It helps us meet compliance requirements, by identifying and fixing vulnerabilities, and to have a robust vulnerability management program. It basically helps keep our company secure, from the application security standpoint.

Snyk also helps improve our company by educating users on the security aspect of the software development cycle. They may have been unaware of all the potential security risks when using open source packages. During this process, they have become educated on what packages to use, the vulnerabilities behind them, and a more secure process for using them.

In addition, its container security feature allows developers to own security for the applications and the containers they run in the cloud. It gives more power to the developers.

Before using Snyk, we weren't identifying the problems. Now, we're seeing the actual problems. It has affected our security posture by identifying open source packages' vulnerabilities and licensing issues. It definitely helps us secure things and see a different facet of security.

It also allows our developers to spend less time securing applications, increasing their productivity. I would estimate the increase in their productivity at 10 to 15 percent, due to Snyk's integration. The scanning is automated through the use of APIs. It's not a manual process. It automates everything and spits out the results. The developers just run a few commands to remediate the vulnerabilities.

• The wide range of programming languages it covers, including Python
• Identifying the vulnerabilities and providing information on how to fix them — remediation steps

It's very easy for developers to use. Onboarding was an easy process for all of the developers within the company. After a quick, half-an-hour to an hour session, they were fully using it on their own. It's very straightforward. Usability is definitely a 10 out of 10. Our developers are using the dashboard and command lines. All the documentation is provided and I've never had an issue.

We have integrated Snyk into our software development environment. It's something that is ongoing at the moment. Our SDE is VS Code.

Another important feature is the solution’s vulnerability database, in terms of comprehensiveness and accuracy. It's top-notch. It pulls all the data from the CVE database, the national vulnerability database. It's accurate and frequently updated.

We use the solution's container security feature. A lot of the vulnerabilities can't be addressed due to OS restraints. They just can't be fixed, even with their recommendations. I would like to see them improve on this.

A feature we would like to see is the ability to archive and store historical data, without actually deleting it. It's a problem because it throws my numbers off. When I'm looking at the dashboard's current vulnerabilities, it's not accurate.

We have been using Snyk for a little more than a year.

The stability is very good. I haven't noticed any downtime.

It provides easy deployment for different code repositories, so it's easily scalable.

We have about 20 to 25 users and it's being used very extensively, across all our applications.

Their technical support is top-notch, a 10 out of 10. I have a Slack channel for direct discussions with support. And I have my account manager for any questions or issues I run into. Response time ranges between instant and three hours. If they don't know the question or the issue, they'll escalate. They'll have someone else join the Slack or give me a Zoom session.

This is the first of its kind, that we are using.

The initial setup was very straightforward. The integrations with our code repositories, like Bitbucket and GitHub, are direct. You enter their required information and just pull data from them. There was no setup for any additional VMs or anything else.

Developer adoption has been pretty positive, since it's easy to use. We have 100 percent adoption. They understand the need for security with software development. Everyone's happy with the product, and it allows them to catch vulnerabilities earlier in the software development cycle, rather than later, so they can fix them before they get to the security-review process.

The deployment took a few hours, maybe even less. I was the only one involved in the process. I just followed the directions. We just planned on identifying the specific repositories linking to Snyk, and then started scanning specific projects.

I also take care of maintenance of the solution and it takes less than 5 percent of my time. There is very little maintenance needed since it's a SaaS product.

We have seen ROI, although I don't have any data points on it. It's very valuable. It saves time for the developers and security team by quickly identifying things and fixing them before they get down the pipeline. It prevents the creation of additional roadblocks and complexity and the pushing out of deadlines to address issues once they are too far down the pipeline.

We didn't find any other options on the market.

The biggest lesson I've learned from using this solution is the complexity of open source licenses. I wasn't aware of all the different types of licenses, and all the terms and conditions required to use specific open source packages.

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.

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

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

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

It helps find issues quickly because:

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

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

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

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

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

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

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

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

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

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

We have been using this product for five months.

The product is sometimes unstable.

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

We currently have 20 developers who use it.

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

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

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

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

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

We did not previously use another solution in this company.

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

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

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

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

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

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

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

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

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

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

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

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

Check the following before using Snyk:

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

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

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

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

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

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

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

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

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

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

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

The most valuable features are their GitLab and JIRA integrations.

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

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

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

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

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

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

I have been using Snyk for about a year.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Snyk acts as an SCA and also as a SAST. It's like a mix and match.

Our deployment is more of a hybrid deployment. It is 70% cloud and 30% on-prem. The majority of Snyk is a cloud-based solution, but we do have instances where we have it on-prem for various reasons.

The advantage of Snyk is that Snyk automatically creates a pull request for all the findings that match or are classified according to the policy that we create. So, once we review the PR within Snyk and we approve the PR, Snyk auto-fixes the issue, which is quite interesting and which isn't there in any other product out there. So, Snyk is a step ahead in this particular area. In the development phase, there are lots of dependencies from one module to another, and if it has to be a manual fix, it takes forever for developers to fix it. We do utilize both functionalities. Sometimes, I get the developers to look at the issues and get them manually fixed, and sometimes, based on the criticality and severity of the finding, I just approve the PR, and Snyk automatically fixes it. I don't need to worry about the dependencies.

All such tools should definitely improve the signatures in their database. Snyk is pretty new to the industry. They have a pretty good knowledge base, but Veracode is on top because Veracode has been in this business for a pretty long time. They do have a pretty large database of all the findings, and the way that the correlation engine works is superb. Snyk is also pretty good, but it is not as good as Veracode in terms of maintaining a large space of all the historical data of vulnerabilities.

I have been using this solution for about two years. 

It is easily scalable, and it is pretty easy to integrate and manage. However, the tuning is what requires a lot of attention. Snyk, Veracode, Netsparker, or any other similar solution definitely needs somebody to tune it to work properly. Tuning is a little bit tricky, but that's the nature of such solutions.

I had to work with them initially during the integration phase. Their support was okay. It was not that good, but it was also not that bad. There is room for improvement because the support works based on the categories of requests. Along with the categories, if they have an option for the sensitivity or the urgency of issues, it would be really helpful for users.

It was pretty easy. 

It is pretty expensive. It is not a cheap product.

I would rate it a seven out of ten.

Snyk is a code analysis tool. It is a vulnerability finding tool. We use it for those purposes. We use this tool to detect issues particular to users.

Snyk is configured on our local ID environment. So our team and many other teams use it to do a scan before they deploy anything in the production.

There are many valuable features. For example, the way the scanning feature works. The integration is cool because I can integrate it and I don't need to wait until the CACD, I can plug it in to our local ID, and there I can do the scanning. That is the part I like best.

Feature wise, I like it so far. Maybe a little bit early to call, but feature wise, I'm okay with it. It may be a little bit expensive, but otherwise, it is a good tool.

I don't have any complaints. Thankfully, I had help in the decision-making and the initial integration. After that, the actual development and ops teams are using it. So if they are facing issues or they have any concerns, I'm not sure about that.

Basically the licensing costs are a little bit expensive.

I have been using Snyk for a year.

It is a stable solution.

In our organization I would say more than 50 and less than a hundred are regularly using Snyk.

Tech support is good. They are reliable and available. Some of the teams are using Snyk and they are not complaining about support. The support is better and they are available whenever we need. We can reach out to them for help.

The initial setup was neither complex nor easy, I would say it was okay.

It took a few weeks.

A few people helped us with the initial setup.

Our experience with them was that they're really good.

Snyk is a security analysis tool. We have other tools, some dynamic security analytics tools, and other tools set up, and we wanted to compare which one we should use. We have Contrast, Coverity, and Snyk, and now we are planning to keep one. That was the main reason I had downloaded the code from your site and from many other sites. In the end we are planning to keep Snyk.

Snyk is good. I like to use it. I like to use Snyk over Contrast.

On a scale of one to ten, I would give Snyk an eight.

There is no complaint here. 

We have been considering Snyk in order to improve the security of our platform, in terms of Docker image security as well as software dependency security. Ultimately, we decided to roll out only the part related to software dependency security plus the licensing mechanism, allowing us to automate the management of licenses.

We have integrated Snyk in the testing phase, like in the testing environment. We are in the process of rolling the solution out across our entire platform, which we will be doing soon. The APIs have enabled us to do whatever we have needed, and the amount of effort for the integration on our end has been reasonable. The solution works well and should continue to work well after the full-scale roll-out.

We expect to get additional benefits in terms of validating our software security. 

The solution does its job to help developers find and fix vulnerabilities quickly. So, it is working well. 

• The platform's ease of use
• Good support from the customer success team 
• A transparent solution
• Functionally coherent and powerful

The overall goal is to have a high security platform delivered in an easy way. This is in terms of the effort that we have to put in as well as cost. From this perspective, Snyk looks like the most promising solution. So far, so good.

It is easy for developers to use. The documentation is clear as well as the APIs are good and easily readable. It's a good solution overall.

We would like to have upfront knowledge on how easy it should be to just pull in an upgraded dependency, e.g., even introduce full automation for dependencies supposed to have no impact on the business side of things. Therefore, we would like some output when you get the report with the dependencies. We want to get additional information on the expected impact of the business code that is using the dependency with the newer version. This probably won't be easy to add, but it would be helpful.

We have been using it for about three months.

So far, we have had no concerns regarding the solution's stability. We have had no downtime.

The scalability is okay.

When it comes to direct users who are managing it or doing the integration for Snyk, then there are a few developers from the team who own the solution.

The goal is to roll this out across all services and supported technologies. Once we finish our rollout phase, then we expect to have full adoption. Thanks to our internal integration, teams will just be seeing the updated dependencies whenever they are available. So, Snyk will be doing the hard magic behind the scenes for everyone.

The customer success team is a solid team. I liked their approach from the very beginning and after signing the contract. They kept things looking good, which is a good sign.

We haven't had an opportunity to validate some hard cases with the technical support yet.

We did not previously use another solution.

The initial setup was easy and nicely documented.

We have been managing the deployment with other initiatives that we are running. We haven't had major obstacles with the deployment so far.

For our implementation strategy, we first worked on the plan of, "How do you want to integrate it?" We investigated the best setup, then we just went to the implementation phase from the research phase.

One software engineer is enough for deployment and maintenance. We had to split the duties of this between several people, but one person is enough. 

Keep extracting knowledge from the Snyk team. They are very helpful during the process, so make sure to use them.

The more security that we have, the more confident we are. You never know when you will be actually attacked. Hopefully, this will not be validated anytime soon in reality. However, by doing our penetration tests, we are validating the system on a regular basis, which will also help improve our overall confidence in this area. 

It gives us peace of mind that there is nothing hidden that hasn't been taken care of. That is also important.

The solution has reduced the amount of time it takes to fix and find problems.

The pricing is reasonable.

For the Docker security feature use case, we decided to go with an open source solution (Trivy), because it is sufficient for our needs. Integration with Trivy was cheap and easy, which makes it cost-effective. Our current use case was simple enough that the existing open source tool was sufficient. Maybe there are use cases that are more advanced and sophisticated, where the open source solution would not be sufficient for an organization. In such cases, the benefits from the paid version would be worth the money. I think it boils down to the specific use case of a company.

We were not able to find a sufficient, elegant solution for the dependencies part of our use case. That is why we invested in our partnership with Snyk. After evaluating paid and open source solutions, Snyk was selected as the best tool.

I have heard from my team that it has a comprehensive database. Hopefully, it will work well during the production usage. Our hopes are high. So far, we haven't seen any downsides.

We have our internal processes for maintaining and updating dependencies in general. We will be incorporating any suggested updates coming from Snyk into our internal, already-existing process and platform, with some additional effort from our teams. Hopefully, there won't be any major additional effort. Hopefully, cases needing additional effort for issues will be rare.

We are using the SAST version of Snyk. Its complexity is reasonable.

I would rate it as an eight out of 10.