Snyk Reviews

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.

We are using Snyk along with SonarQube, and we are currently more reliant on SonarQube.

With Snyk, we've been doing security and vulnerability assessments. Even though SonarQube does the same when we install the OWASP plugin, we are looking for a dedicated and kind of expert tool in this area that can handle all the security for the code, not one or two things.

We have the latest version, and we always upgrade it. Our code is deployed on the cloud, but we have attached it directly with the Azure DevOps pipeline.

It is a nice tool to check the dependencies of your open-source code. It is easy to integrate with your Git or source control. 

It has a nice dashboard where I can see all the vulnerabilities and risks that they provided. I can also see the category of any risk, such as medium, high, and low. They provide the input priority-wise. The team can target the highest one first, and then they can go to medium and low ones. 

Its reports are nice and provide information about the issue as well as resolution. They also provide a proper fix. If there's an issue, they provide information in detail about how to remediate that issue.

It is easy to integrate without a pipeline, and we just need to schedule our scanning. It does that overnight and sends the report through email early morning. This is something most of the tools have, but all of these come in a package together.

It never failed, and it is very easy, reliable, and smooth. 

It would be great if they can include dynamic, interactive, and run-time scanning features. Checkmarx and Veracode provide dynamic, interactive, and run-time scanning, but Snyk doesn't do that. That's the reason there is more inclination towards Veracode, Checkmarx, or AppScan. These are a few tools available in the market that do all four types of scanning: static, dynamic, interactive, and run-time.

We have to integrate with their database, which means we need to send our entire code to them to scan, and they send us the report. A company working in the financial domain usually won't like to share its code or any information outside its network with any third-party provider. Such companies try to build the system in-house, and their enterprise-level licensing cost is really huge. There is also an overhead of updating the vulnerability database.

It has been more than one and a half years. 

It is stable. I haven't had any problems with its stability.

It is easy. We have integrated Snyk with two to four projects, and we do run scanning every week to check the status and improvement in the quality of our code.

Currently, only I am using this solution because I'm handling all the stuff related to infrastructure and DevOps stuff in my company. It is a very small company with 100 to 200 people, and I am kind of introducing this tool in our organization to have enterprise-level stuff. I have used this tool in my old organization, and that's why I am trying to implement it here. I am the only DevOps engineer who works in this organization, and I want to integrate it with different code bases.

I've never used their technical support.

It is really straightforward. If someone has set up a simple pipeline, they can just integrate in no time.

Pricing-wise, it is not expensive as compared to other tools. If you have a couple of licenses, you can scan a certain number of projects. It just needs to be attached to them.

I have been using this solution for one and a half years, and I definitely like it. It is awesome in whatever it does right now.

It is a really nice tool if you really want to do the dependency check and security scanning of your code, which falls under static code analysis. You can implement it and go for it for static code analysis, but when it comes to dynamic, interactive, and run-time scanning, you should look for other tools available in the market. These are the only things that are missing in this solution. If it had these features, we would have gone with it because we have already been using it for one and a half years. Now, the time has come where we are looking for new features, but they are not there.

Considering the huge database they have, all the binaries it scans, and other features, I would rate Snyk an eight out of 10. 

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.

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 use Fugue to gain better visibility. It enhances the ability of Kubernetes operational management within the Azure platform. We use it to extend, monitor, and operationally manage the capabilities of Kubernetes' workloads.

Gain visibility and fine-grained monitoring capabilities for complex Kubernetes environment

Fugue provides core capabilities that enable visualization, discovery, and compliance automation.

These Fugue capabilities are delivered as software as service and were easy to consume.

Combined with Slalom’s advisory, solution integration, and cybersecurity services, Fugue was straightforward to implement and deploy.

It would be ideal if there was customization with a focus on specific cybersecurity areas or capabilities. Fugue is cybersecurity, an operational monitoring solution, which has a broad set of capabilities. However, one needs to have substantial know-how in the cybersecurity domain to be able to identify and zero in on specific Fugue capabilities that may be relevant to a particular project or workstream pursuit. 

Being a system integrator, for us, it isn't an issue. For a client that is new to Fugue or relatively new to cybersecurity, it would be quite challenging to zero in on a specific sweet spot or capability.

I've been using the solution for about eight months to a year at this point. We have multiple teams in our organization that use the solution for various periods of time.

We've been impressed with the stability fo the solution. It doesn't crash or freeze. It's not glitchy. It's reliable.

The scalability is excellent and hasn't let us down. If a company needs to expand the solution, they can do so with relative ease.

Currently, in our organization, about 100 people actively use it.

The solution's technical support is quite good. We have a model of Alliance partnerships. We have well defined and well-orchestrated working relationship with Fugue, being a system integrator and partner. It works well.

we use Fugue and Alcide to extend and augment existing 'native features' of azure

The solution's initial setup wasn't complex at all. It was pretty straightforward.

We're an integrator and reseller. We handle implementations for clients.

I'm unsure of the costs associated with the solution.

We used Fugue in combination with Alcide.io

We're a Fugue partner.

In terms of which version we are using, I would have to say that it was the latest one that we worked with. The exact number version escapes me. I would have to go back and check. 

The solution was specifically deployed to assist with cloud management of Azure in a specific case, however, we are using it across all of the cloud supply platforms including Google Cloud and AWS.

I would absolutely recommend this solution to others.

Overall, I would rate the solution at an eight out of ten. It works well, however, a user needs to be fairly knowledgable in cybersecurity in order to get the most use out of it.

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

We've been using Snyk for about 18 months.

The stability is pretty good.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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