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

We are using Snyk to find the vulnerabilities inside dependencies. It is one of the best tool in the market for this. 

It is pretty easy and straightforward to use because integration won't take more than 15 minutes to be honest. After that, developers don't have to do anything. Snyk automatically monitors their projects. All they need to do is wait and see if any vulnerabilities have been reported, and if yes, how to fix those vulnerability. 

So far, Snyk has given us really good results because it is fully automated. We don't have to scan projects every time to find vulnerabilities, as it already stores the dependencies that we are using. It monitors 24/7 to find out if there are any issues that have been reported out on the Internet.

Whenever Snyk reports to us about a vulnerability, it always reports to us the whole issue in detail:

• What is the issue.
• What is the fix.
• What version we should use.

E.g., if upgrading to a new version may break an application, developers can easily understand the references and details that we receive from Snyk regarding what could break if we upgrade the version.

The solution allows our developers to spend less time securing applications, increasing their productivity. As soon as there is a fix available, developers don't have to look into what was affected. They can easily upgrade their dependencies using Snyk's recommendation. After that, all they need is to test their application to determine if the new upgrade is breaking their application. Therefore, they are completely relaxed on the security side. 

Snyk is playing a big role in our security tooling. There were a couple of breaches in the past, which used vulnerability dependencies. If they had been using Snyk and had visibility into what vulnerabilities they had in their dependencies, they could have easily patched it and saved themselves from their breaches.

So far, we have really good feedback from our developers. They enjoy using it. When they receive a notification that they have a vulnerability in their project, they find that they like using Snyk as they have a very easy way to fix an issue. They don't have to spend time on the issue and can also fix it. This is the first time I have seen in my career that developers like a security tool.

I'm the only person who is currently maintaining everything for Snyk. We don't need more resources to maintain Snyk or work full-time on it. The solution has Slack integration, which is a good feature. We have a public channel where we are reporting all our vulnerabilities. This provides visibility for our developers. They can see vulnerabilities in their projects and fix them on their own without the help of security.

Snyk integrations and notifications with Slack are the most valuable feature because they are really handy. By monitoring dependencies, if there is a vulnerability reported, Snyk will fire off a Slack message to us. With that Slack message, we can create a request just from the notifications which we receive on Slack. It's like having visibility in a general channel and also flexibility to fix that issue with a few clicks.

The solution’s vulnerability database is always accurate since the chances of getting a false positive is very rare. It only reports the vulnerabilities which have already been reported publicly.

The solution’s Container security feature allows developers to own security for the applications and the containers they run in in the cloud. Without using Snyk, developers might be not aware if they are creating a vulnerability in their Docker images. While using Snyk, they have at least a layer of protection where they can be notified by a Snyk if there is a vulnerability in the Docker images or communities.

If the Snyk had a SAST or DAST solution, then we could have easily gone with just one vendor rather than buying more tools from other vendors. It would save us time, not having to maintain relationships with other vendors. We would just need to manage with one vendor. From a profitability standpoint, we will always choose the vendor who gives us multiple services. Though, we went ahead with Snyk because it was a strong tool.

Snyk needs to support more languages. It's not supporting all our languages, e.g., Sift packages for our iOS applications. They don't support that but are working to build it for us. They are also missing some plugins for IDEs, which is the application that we are using for developers to code.

There are a couple of feature request that I have asked from Snyk. For example, I would like Snyk to create a Jira ticket from Slack notifications. We already have Snyk creating a pull request from Slack notifications, so I asked if we could create a Jira ticket as well so we can track the vulnerability.

I started working with at my company eight months ago and Snyk was already in place. As for my own experience, I was using this solution before I joined the company, so I was familiar with the tool and how it works.

They were a couple of issues which happened because Snyk lacked some documentation on the integration side. Snyk is lacking a lot of documentation, and I would like to see them improve this. This is where we struggle a bit. For example, if something breaks, we can't figure out how to fix that issue. It may be a very simple thing, but because we don't have the proper documentation around an issue, it takes us a bit longer.

So far, we have onboarded all our developers to Snyk, and it's still running fine. However, they could improve it. For example, if I create a bulk request for more than 15 or 20 vulnerabilities, then it takes a bit longer than it should in terms of time.

Including security, the total developers that we have on Snyk is almost 50 at this time. We are pushing more to the developers and would like to have 200 developers in the coming month or two.

The people with whom I'm connected are really good. If I have issues, they will quickly jump on a call and I will start troubleshooting with them over the call. The people with whom I'm talking are very technical.

Before using Snyk, we didn't have visibility into how many dependencies we were using or importing into our projects. Snyk gives us how many third-party libraries we are using and what version they are running on. Also, it let us know if there are any vulnerabilities in those libraries when we are writing our code. Because of the potential impact, we have to ensure that there aren't any vulnerabilities in these libraries (since we have no visibility) when we are importing. 

The initial setup was straightforward. Onboarding projects didn't take me too long. It was pretty straightforward and easy to integrate with event/packet cloud and import all our projects from there. Then, it was easy to generate the organizational ID and API key, then add it to the Snyk plug-in that we are using in our build pipeline.

Snyk was already onboard when I joined. Deployment of my 23 projects took me an hour. 

The solution has reduced the amount of time it takes to find problems by three or four hours per day. 

The solution has reduced the amount of time by at least two to three hours a day to fix problems because the documentation which we receive is very helpful. This also depends on a couple of factors, such as, how big a project or library is.

Developer productivity has increased a lot. Considering all the projects about security vulnerabilities, we are saving at least six to seven hours a day.

It saves a lot of my time and the developers' time. Also, because everything is super simple and straightforward in one place, it is really convenient for the security team to keep an eye on vulnerabilities in their projects.

Having this type of tool for a security team is really helpful. In my previous role, we didn't have this type of tool for our team. We struggled a lot with how we could enhance our visibility or see our projects: what dependencies they were using and if we could monitor those dependencies for any vulnerabilities. Without the tool, we could be attacked by some random vulnerability which we were not even aware of. Thus, I strongly recommend having this type of tool for a security team.

This is integrated with our CI/CD.

For Containers, we are still not fully rolled out and working around it. 

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

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.

We use Snyk to check vulnerabilities and rectify potential leaks in GitHub.

The tool's initial use is complex. 

I have been working with the product for three to four months. 

I rate the product an eight out of ten. 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

I have been using Snyk for about two years.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Snyk's major use case is to check our code for vulnerabilities that may exist in the dependencies or the security of the code. This allows developers to identify and address potential security issues that can be resolved.

Snyk offers two key advantages for organizations. Firstly, it allows all issues to be fixed in one centralized location, streamlining the process of addressing vulnerabilities. Secondly, Snyk categorizes the level of vulnerability into high, medium, and low, which helps organizations prioritize which issues to tackle first. This feature ensures that low-priority vulnerabilities are not addressed before high-priority ones.

One area where Snyk could improve is in providing developers with the line where the error occurs.

As of now, I have been using Snyk for two weeks. Also, I am using the latest version of the solution. So, my company is an end-user and customer of the solution.

I haven't faced any stability issues at all while using the solution. Stability-wise, it is a fine product. I rate its stability a nine out of ten.

Only three users are using the solution in my company. Even though there are around fifteen developers in my company, since the solution is still in the integration stage, many developers can't use it yet. So, once the seniors get accustomed to Snyk, then the juniors will follow.

From a scalability standpoint, I haven't explored the solution yet.

I haven't faced any issues that I can take to them. So, all the documents Snyk provides have solutions to the potential issues one could face. I did not need to use the internet to check for the resolutions to my issues with the solution.

I have used SonarQube previously. We still use SonarQube and might migrate to Snyk completely in the future. Also, we may even consider using both parallelly.

SonarQube notifies us of the error. It also mentions the line where that error is and gives the exact line of code along with the line number. While it doesn't give any solution, it does give an alternate solution. So, it will just show what can be removed, where the vulnerabilities are, and what needs to be changed.

In Snyk, it notifies its user what an old version is and how to take it to another stable version. It also notifies its users about the vulnerabilities in a version before suggesting a new version that doesn't have such vulnerabilities.

Integration in Snyk was easier since, during SonarQube's integration process in our company, we always faced technical issues during its setup or while trying to operate it. Snyk is a very user-friendly tool, giving it a huge plus point.

SonarQube detects in a code if any line is commented or any variable is defined but not used. Snyk, on the other hand, doesn't detect such details but detects vulnerabilities on a higher level.

The deployment model for the solution is a cloud-based one.

Regarding Snyk's deployment, we have integrated everything with Jenkins so that the deployment happens automatically. Also, in Jenkins itself, we have integrated Snyk. The deployment process for Snyk took less than an hour. Once a person goes through the documents provided by Snyk, the deployment process becomes easy. The deployment process in my company was carried out without needing any help from external sources.

Presently, my company uses an open-source version of the solution. The solution's pricing can be considered quite reasonable owing to the features they offer. There are no extra costs attached to the solution because there is no need for extra hardware or other software since it has been integrated with the Jenkins CICD automation pipeline, and the dashboard gives everything in one place.

Upon reviewing Snyk's operations, I found it helpful, although not entirely comprehensive. Specifically, it provides valuable information regarding the status of vulnerabilities and the details of dependencies used in our projects. The solution also can identify issues that could be resolved manually or through alternative means. Snyk gives all the required information, while SonarQube doesn't. In SonarQube, data is presented in a different format that is required to be reviewed by us on a line-by-line basis. One of Snyk's strengths was its ability to consolidate all identified issues into a single location.

Currently, our company has not utilized any expensive solutions. So, we opted for SonarQube's open-source version. In the future, if the need arises, we may consider purchasing a solution. However, as this is for a proof-of-concept (POC), I am currently exploring trial or open-source versions, which are free of cost. If a solution is successfully integrated into our projects and our developers become familiar, we may consider purchasing a particular solution. For now, we are focusing on finding a solution that meets our needs for the POC without incurring any unnecessary expenses.

I would definitely recommend the solution to those planning to use it. Overall, I rate the solution a seven and a half out of ten. To be more specific, I would rate it an eight out of ten.

The solution is set up in a test lab for proof of concept on the ACIA component. Our client is proposing the solution in an RFP response that will include 3,000 users when awarded. 

The solution has great features and is quite stable. 

The log export function could be easier when shipping logs to other platforms such as Splunk. 

I have been using the solution for months.

The stability is quite good. 

The solution is scalable with no issues. 

I have not needed technical support. 

The initial setup is quite straightforward and took fifteen minutes. 

We implemented the solution in-house. 

In our lab environment, the deployment strategy is to install and run with no complex operations. 

I rate the solution a nine out of ten. 

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

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

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

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

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

The most valuable features include 

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

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

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

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

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

We have been using Snyk for about a year.

I haven't noticed any stability issues.

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

It's scalable.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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