Snyk Reviews

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.

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.

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 the product to scan our code for any vulnerable dependencies we might have. We depend on open source libraries and need to make sure they're secure. If not, we need to highlight the areas and replace them, update them quickly. A secondary, minor use case is to also look at licensing and make sure that we're not using open source licenses we should not be using. Those are our two use cases.

What is valuable about Snyk is its simplicity, and that's the main selling point. It's understandably also very cheap because you don't need as much account management resources to manage the relationship with the customer and that's a benefit. I also like that it's self-service, with extremely easy integration. You don't need to speak to anybody to get you off and running and they have loads of integrations with source control and cloud CI systems. They are a relatively new product so they might not have a bigger library than competitors, but it's a good product overall.

They do however have the option to install Snyk on-prem, but it is much more expensive.

The product could be improved by including other types of security scanning (e.g. SAST or DAST), which is important. It would also help to include the static analysis specifically to the open-source scanning so we could get an idea of whether a particular library is vulnerable and recognise if we're actually using the vulnerable part of it or not, they do have runtime analysis, but it is a hassle to set up.

It would be the same issue in terms of the inclusion of additional features. I think static analysis is really important. A second additional feature would be to add tags to projects, identifying an important project or assigning a project to a particular team. Custom tags would be helpful.

I've been using the product for less than a year. It's an SaaS solution, online, so we're always using the latest version. 

It's a very stable product, they are clear when a specific feature is in beta.

We have hundreds of source code repositories, and Snyk scans them in minutes (it just looks at package management files to identify the dependency tree), Snyk uses the same infrastructure to scan for all customers on the cloud which gives it lots of scalability opportunities compared to some other vendors where the software is installed on-prem or on a dedicated instance which makes the software pricy and limited (this dedicated instance will be idle most of the time, and the customer needs to pay for it).

The technical support is very good. 

Some of our products are deployed on the private cloud behind firewalls, Snyk has tools to carry out security scanning from our private repositories. 

For anyone thinking of using the product, I would suggest using cloud and SaaS providers. Generally, they are easy to work with and there's no hassle of having to talk to salespeople and arrange demos, etc. Self-service SaaS products are a good way to go when it's appropriate.

I would rate this product a nine out of 10.

I am using Snyk for DevOps and security.

The most valuable features of Snyk are vulnerability scanning and automation. The automation the solution brings around vulnerability scanning is useful.

The solution could improve the reports. They have been working on improving the reports but more work could be done.

I have been using Snyk for a few months.

The stability of Snyk is good.

We have not had any challenges with the scalability of Snyk.

There are good resources to answer questions when we have issues.

I have not used a testing solution prior to Snyk.

The initial setup of Snyk was easy.

The price of the solution is expensive compared to other solutions.

I would recommend people use the free tier first before they purchase.

I rate Snyk a ten out of ten.

We are using Snyk for two main reasons: 

1. Licensing. For every open source package that we're using, we have licensing attributions and requirements. We are using Snyk to track all of that and make sure we're using the licenses for different open source packages that we have in a compliant fashion. This is just to make sure the licensed user is correct. 
2. Vulnerabilities. Snyk will report on all the vulnerabilities present in all our different packages. This is also something we'll use to change a package, ask the desk to fix the vulnerability, or even just block a release if they are trying to publish code with too many vulnerabilities.

I am using the latest SaaS version.

Our whole process of deploying code uses Snyk either as a gateway or just to report on different build entities. 

The solution's ability to help developers find and fix vulnerabilities quickly is a great help, depending on how you implement it at your company. The more you empower your developers to fix their stuff, the less policies you will have to implement. It's a really nice feeling and just a paradigm shift. In our company, we had to create the habit of being proactive and fixing your own stuff. Once the solution starts going, it eases a lot of management on the security team side.

Snyk's actionable advice about container vulnerabilities is good. For the Container tool, they'll provide a recommendation about what you can do to fix your Docker, such as change to a slimmer version of the base image. A lot of stuff is coming out for this tool. It's good and getting better.

The solution’s Container security feature allows developers to own security for the applications and the containers they run in in the cloud. That is its aim. Since we are letting the developers do all these things, they are owning the security more. As long as the habit is there to keep your stuff up-to-date, Snyk won't have any effect on productivity. However, it will have a lot of effect on security team management. We put some guardrails on what cannot be deployed. After that, we don't have to check as much as we used to because the team will just update their stuff and try to aim for lower severities.

Our overall security has improved. We are running fewer severities and vulnerabilities in our packages. We fixed a lot of the vulnerabilities that we didn't know were there. Some of them were however hard to exploit, mitigating the risks for us, e.g., being on a firewalled server or unreachable application code. Though I don't recall finding something where we said, "This is really bad. We need to fix it ASAP."

I find many of the features valuable: 

• The capacity for your DevOps workers to easily see the vulnerabilities which are impacting the code that they are writing. This is a big plus. 
• It has a lot of integration that you can use even from an IDE perspective and up to the deployment. It's nice to get a snapshot of what's wrong with the build, more than it is just broken and you don't know why. 
• It has a few nice features for us to manage the tool, e.g., it can be integrated. There are some nice integrations with containers. It was just announced that they have a partnership with Docker, and this is also nice. 

The baseline features like this are nice. 

It is easy to use as a developer. There are integrations that will directly scan your code from your IDE. You can also use a CLI. I can just write one command, then it will just scan your old project and tell you where you have problems. We also managed to integrate it into our build pipeline so it can easily be integrated using the CLI or API directly, if you have some more custom use cases. The modularity of it is really easy to use.

Their API is well-documented. It's not too bad to integrate and for creating some custom use cases. It is getting extended going forward, so it's getting easier to use. If we have issues, we can contact them and they'll see if they can change some stuff around. It is doing well.

Most of the solution's vulnerability database is really accurate and up-to-date. It has a large database. We do have some missing licenses issues, especially with non-SPDX compliant one, but we expect this to be fixed soon. However, on the development side, I rarely have had any issues with it. It's pretty granular and you can see each package that you're using along with specific versions. They also provide some nice upgrade paths. If you want to fix some vulnerabilities, they can provide a minor or major patch where you can fix a few of them.

• More visibility on the package lifecycle because we are scanning our application at different point (DevOps, Security, QA, Pipeline, Production Env) and all those steps get mixed together in the UI. Therefore, it's hard to see the lifecycle of your package.

• Docker base image support was missing (Distroless) but support is increasing.

• UI taking some time to load. We have a lot of projects in the tool.

Snyk is responsive and they work to fix the pain points we have.

For two years.

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

Scalability has some issues because we have a lot of code and its use is mandatory. Therefore, it can be slow at times, especially because there are a lot of projects and reporting. Some UI improvements could help with this. 

From a scan time perspective, everything is pretty fast.

All our developers and the security team use it. There are probably around 100 people using it whose roles are mainly developers, along with a few security analysts and architects.

We have good communication with Snyk. They make us feel like a valued customer and provide us with a Customer Success Manager and training for our teams.

I haven't contacted technical support. One of my teammates did contact them and was pleased with the results. 

We were previously using another vendor for vulnerability management. We decided to use Snyk in parallel to handle licence reporting. One issue that we had with our previous vendor was that we were promised features that were never delivered. It also had some quirks that weren't fitting our needs. Since we already had Snyk, and it could do vulnerability reporting, we decided to keep Snyk for the two use cases.

I wasn't part of the initial setup. It was done by another team. From what I heard, it wasn't too much of a hassle to set up. Though, my team hasn't been 100 percent satisfied with how it was set up by us, as we could do so much more with the tool..

We have seen ROI from a security perspective.

The solution has reduced the amount of time it takes to find and fix problems, especially to fix them. Without Snyk, we had no visibility on open source package vulnerabilities. We started from not seeing anything to fixing them. Since we had to wait for an incident or fortuitous discovery before, it has been a good improvement.

At first, we were using it only for scanning the images that were getting sent to production. Then, we added the entire workload running on our clusters. This increased our vulnerabilities because there were duplicates, but also gave more visibility.

The more you put into learning the tool, the better results you will get. Even if it's easy to use, you do need to create the habit of using it with your DevOps. Once it's integrated, it will be a lot easier. You'll see quickly the issues that you can fix when you're writing your code and don't have to wait until the end of QA to be denied.

I don't see anything Snyk can report as a false positive because the vulnerability database is there and the vulnerable code in the package. It just depends on how you invoke the code. Unless they start scanning the code, they cannot know. From that perspective, false positives are pretty low, almost non-existent.

Our developers are spending more time working on Snyk issues than before, mainly because they were not aware of things that they needed to fix. The process is easy to fix something, so it neither increases nor decreases our developer productivity.

It does require a bit of time, especially when creating the habit of using the tool, but the investment is worth it. It enables developers to own security. If you can get the developers to own security, you are reducing a lot of weight off of your security team. Then, you don't need to have such a big security team because the solution offloads a lot of work.

Get the developers on your side. We managed to make it mandatory, but this won't happen everywhere. If a developer takes a solution to heart in a project and really wants to use it, it'll go well. Otherwise, if you keep fighting against them, then it will be a hassle.

If Snyk offered a SAST/DAST solution, we would be interested in testing it out. We have good experience with the platform and we could consolidate our efforts with them. We are not super satisfied with our current SAST implementation.

What I want for the future is to get more proactive adoption instead of adopting because it is mandatory. Adoption will grow, especially if Snyk have other features coming in. We enjoy the product.

I would rate the solution as a 9 (out of 10).

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. 

In my company, Snyk is useful because it provides container security and DAST.

Snyk is a strong security solution that helps customers analyze static code and improve their security and code in their main application.

DAST has shortcomings, and Snyk needs to improve and overcome such shortcomings.

I have experience with Snyk, and it is a new solution chosen by my company. I am a reseller of the solution.

It is a stable solution. Stability-wise, I rate the solution a ten out of ten.

Scalability-wise, I rate the solution an eight out of ten.

One security engineer uses Snyk in our company, but we don't use the tool for our own use cases, and we only deploy it for our customers.

I rate the technical support a ten out of ten.

Positive

Our company previously used Micro Focus for three or four months. We have worked with Checkmark for more than two or three years.

We provide Snyk to our customers. It is a very strong solution.

I rate the initial setup a ten on a scale of one to ten, where one is difficult, and ten is easy.

The solution is deployed on the cloud since it is a SaaS solution and doesn't have an on-premises version.

The deployment process for Snyk takes like a week.

For the steps in Snyk's deployment, one has to buy a license and click on the deploy icon on Snyk's website, after which it syncs up with the system.

One person is required for deployment. Even if we talk about something like container security or DAST, only one person would be required for the deployment process.

On a scale of one to ten, where one is cheap and ten is expensive, I rate the pricing a three. It is a cheap solution.

I would definitely recommend the solution to those planning to use it since it is easy to deploy and has strong features like machine learning and the ability to analyze static codes.

Overall, I rate the solution an eight out of ten.