Snyk Reviews

Our customers use Snyk for infrastructure scanning, SaaS testing, and continuous vulnerability scans. 

Our customers find container scans most valuable. They are always talking about it.

Offering API access in the lower or free open-source tiers would be better. That would help our customers. If you don't have an enterprise plan, it becomes challenging to integrate with the rest of the systems. Our customers would like to have some open-source integrations in the next release.

I have known about Snyk for about two years.

Snyk is a stable solution. I don't think we faced any issues with it.

Snyk is a scalable product. 

We used to work with SonarQube, which is fast. We also used CoreOS Clare and explored Prisma. The open-source and self-hosted solutions are better suited for smaller startups. They only have to spend on setting it up as running is entirely free.

The initial setup is straightforward because it's a SaaS solution. I didn't have any problems implementing this solution. I think installing and deploying this solution took me about 15 minutes.

I implemented this solution. 

The pricing is acceptable, especially for enterprises. I don't think it's too much of a concern for our customers.  Something like $99 per user is reasonable when the stakes are high.

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

I used it for the security analysis and code vulnerability part. We were also interested in integrating with the pipeline scan and code scan.

The code scans on the source code itself were valuable.

It's very easy to use. It's very fast. 

It was good, but we had a few limitations with it. We were mostly using containerized applications. We were using Microsoft Docker images. It was reporting some vulnerabilities, but we were not able to figure out the fix for them. It was reporting some vulnerabilities in the Docker images given by Microsoft, which were out of our control. That was the only limitation. Otherwise, it was good.

I used it two months ago for a period of two weeks.

Its stability was good during that two-week period.

We didn't do extensive tests on it.

We contacted them for support. They were responsive, and they responded quickly.

We were using Veracode, but with Veracode, we found some limitations. It was not able to scan the source code the way Snyk does. That's a limitation, and Veracode is not that capable even for container applications. From the capability perspective, it was not as good as Snyk.

It's very easy to use. It's very quick. I'd rate it a nine out of ten in terms of the ease of the setup.

Cost-wise, it's similar to Veracode, but I don't know the exact cost. 

I'd recommend the code quality scan, which is helpful for the upfront feedback for developers. It's a very good feature. The container scans are also good, but only for Microsoft images, there are some limitations. If I were to start looking for a vulnerability solution, I'd definitely go with Snyk. It's quick and easy to use.

Overall, I'd rate Snyk a nine out of ten.

At a high level, Fugue extends and augments compliant reporting capabilities provided by major cloud suppliers. It enhances the visibility, again, from a compliance standpoint, into cloud-based or multi-cloud-based environments.

The solution offers good flexibility in customization. From a compliance and visibility reporting perspective, the fact that it can be applicable for multi-cloud environments is very helpful. It's not a single cloud supplier. It's most of them. The fact that it provides visibility, compliance-related visibility, that is not readily available by cloud suppliers themselves, is its most valuable aspect. It's the additional set of compliance reporting and compliance visibility features that Fugue provides that is what makes it so very useful.

The initial setup is simple and straightforward. 

I can't comment if there are missing features at this time. For the last six to eight months I didn't work with Fugue. I don't have an up-to-date product roadmap to comment on what is or is not available, what they do or do not provide. I would need to review their current roadmap to be able to accurately comment on what is or is not available.

Fugue capabilities are not well understood on the market. If there was one thing they could improve, it would be to basically explain in simple terms to market what it is they do. Right now, understanding what they do requires substantial experience and expertise. It wasn't a challenge for me to identify this area, however, I'm the exception. Generally speaking, there is not sufficient understanding in the broad market of what Fugue does. This is the area they need to focus on.

The general input I have is that there is an opportunity for them to better align with other similar tools and better align with similar capabilities that cloud suppliers deliver natively. What happens is they extend and augment capabilities that cloud suppliers offer. There is additional integrational and operational benefits that can be realized in how they extend and how they position themselves as compared to what cloud suppliers deliver.

I've used the solution for some time. It's likely been more than a year. There were a couple of specific projects which were two months long in terms of duration. I'd work with it on and off for those.

There was no issue with scaling at the time I was deploying it. I did not have a chance to work with it at a really industrial scale, such as an enterprise scale. It was a fairly limited deployment, a fairly limited project. I did not see any issues with the scalability of the architecture or the environment itself.

I worked with their professional services organization. I did not have a chance to go to support, so I cannot comment on the efficiency or effectiveness of the support organization. I didn't interact with them.

The setup was actually fairly simple and they can start delivering value in a very short time. That said, t business value is a subjective thing. The business value itself is something that they need to explain. It's not self-evident.

There were no issues related to the setup. It's a cloud-native solution. It's available nearly instantaneously. Being able to interpret the results and being able to consume the value that they provide and understand the value that they provide, however, needs to be better explained to the market.

The Fugue solution can be handled by a relatively small team - so long as they understand it.

In general, for maintenance, the team is relatively small, however, the level of understanding that the team needs to possess, to have, in order to effectively use it, is quite high.

I don't have direct visibility and the pricing, from what I understand, is negotiable. It's not an effective area for me to comment on.

Considering that they deliver a unique set of capabilities, the money that they charge is likely worth it. That said, one needs to understand the value to fully appreciate it.

We are consultants. We don't have any alliance or partnership relationship. It's similar to the relationship with other technology suppliers that we have in the same space.

I'd advise others to definitely try it out. 

I would rate the solution at an eight out of ten. 

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.

I use Snyk to review my code. 

Snyk helps me pinpoint security errors in my code. 

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

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

I rate Snyk support eight out of 10. 

Positive

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

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

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

I rate Snyk seven out of 10. 

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.

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

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

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

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

I have been using Snyk for several years.

The stability of Snyk is good.

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

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

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

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

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

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

I rate Snyk an eight out of ten.

We are using 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.