Snyk Reviews

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

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

We're using the cloud version.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The main tool today is used to check for security issues in our products. We use it to analyze all the projects, and our security efforts are based partly on this tool.

There are major impacts related to increasing security awareness and managing risks. Snyk has been an essential tool in that aspect.

The valuable aspect is its security capabilities. The tool finds any major issue, and the code is blocked from being promoted to production until the issue is corrected.

I'm not responsible for the tool. As far as I know, there are no major concerns or features that we lack. We had some issues integrating into our pipeline, however, they were resolved.

We have used Snyk for approximately one year.

There are no complaints from the security team. There seem to be no major issues of concern.

The security team is responsible for this tool. I don't have more details, however, there are no complaints, so I believe that's okay.

I don't know about the support or customer service details. It's another team's responsibility.

Positive

I don't have experience with other products similar to Snyk.

I wouldn't be able to say what the company's ROI is.

The pricing and setup are not my responsibilities, so I don't know any details.

I have not evaluated any other solutions.

Based on our experience and what I have heard internally, I would recommend Snyk.

I'd rate the solution nine out fo ten.

Snyk is a security software offering. It helps us identify vulnerabilities or potential weaknesses in the third-party software that we use at our company. 

The solution is meant to give you visibility into open source licensing issues, which you may not necessarily be aware off, such as the way you ingest libraries into your application code for third-party dependencies. There is visibility into anything that could be potentially exploited. 

It provides good reporting and monitoring tools which enable me to keep track of the vulnerabilities found now and/or discovered in the future. It is pretty proactive about telling me what/when something might need mitigation.

Their strength is really about empowering a very heterogeneous software environment, which is very developer-focused and where developers can easily get feedback. If you integrate their offering into the software development life cycle (SDLC), you can get pretty good coverage from a consumer perspective into the libraries that you're using.

It's a good suite of tools tailored and focused towards developers. It ensures their code is safe in regards to their usage of third-party libraries, e.g., libraries not owned or controlled, then incorporated into the product from open sources.

It is meant to be a less intrusive type of solution. It is easy to integrate and doesn't require a lot of effort. It's more a part of the CI/CD pipelines, which doesn't necessarily interfere with developers other than if there are actions/remediations to be taken. From a development impact, it's very lightweight and minimal. 

It is not noticeable for most engineers since it's part of the pipeline. If no new findings are reported, then it goes through without any signals or noise. If there were findings, these are usually legitimate findings and can be configured in such a way that they can be blocked/stopped in your pipelines or be more informational. The user has all the knobs and screws to turn and tweak it towards their use case because there may be areas where security is more critical than in other parts of the company, like development projects. 

We exclusively use their SDE tools. Our CI/CD environments are powered by source code control systems like GitLab and GitHub. BitPocket has also been integrated to some extent. There are CI/CD pipelines where we pull in Snyk as part of the pipeline, jobs, Jenkins environment, etc.

It is a fairly developer-focused product. There are pretty good support and help pages which come with the developer tools, like plugins and modules, which integrate seamlessly into continuous integration, continuous deployment pipelines. E.g., as you build your software, you may update your dependencies along with it. Packages that it supports include CI/CD toolchains, build tools, various platforms, and software/programming languages.

It is one of the best product out there to help developers find and fix vulnerabilities quickly. When we talk about the third-party software vulnerability piece and potentially security issues, it takes the load off the user or developer. They even provide automitigation strategies and an auto-fix feature, which seem to have been adopted pretty well. 

Their focus is really towards developer-friendly integrations, like plug and play. They understand the ecosystem. They listen to developers. It has been a good experience so far with them.

There were some feature requests that we have sent their way in the context of specific needs on containers, like container support and scanning support. 

There are some more language-specific behaviors on their toolchains that we'd like to see some improvements on. The support is more established on some than others. There are some parts that could be fixed around the auto-fix and automitigation tool. They don't always work based on the language used.

I would like them to mature the tech. I am involved with Java and Gradle, and in this context, there are some opportunities to make the tools more robust.

The reporting could be more responsive when working with the tools. I would like to see reports sliced and diced into different dimensions. The reporting also doesn't always fully report.

Scanning on their site, to some extent, is less reliable than running a quick CLI.

We have been engaging with Snyk for close to a year.

I have not encountered any instabilities at this point. 

We have seen cases where tools didn't find or recognize certain dependencies. These are known issues, to some extent, due to the complexity in the language or stack that you using. There are some certain circumstances where the tool isn't actually finding what it's supposed to be finding, then it could be misleading. 

As a SaaS offering, it's been fairly stable.

We have an on-prem type of broker setup, which seems to be a fairly stable. I'm not aware of any particular outages with it. 

We have no concerns regarding scalability. We operate at scale. Their approach is pretty lightweight for integrating tools locally.

We are not fully rolled out across the company; parts of the company are using it more than others. There are some best practices that we still have to establish across our development teams so it feels consistent across our scalable processes. 

I would gauge the technical support as pretty good from our interactions. We are in a licensed partnership, so the response and support that we're getting is part of our license. For quick resolutions, we have standing channels, like Slack, where we can easily get a hold of somebody who can jump in and provide some feedback. The ticketing support system is for medium to long-term requests. It's been pretty good in terms of responsiveness and their ability to support in a very reasonable time frame. Responding in less than a few hours is common in regards surfacing issues and obtaining proactive support with someone who can chime in and provide potential resolution strategies.

The product is tailored towards developers. It has a good implementation and support team who provide quick resolution on support issues. Their support listens to feedback. We engage with them, and they listen to developers' needs. They have also been pretty good in terms of turning things around. Even though we hadn't done a major request with them, they're very supportive, open, and transparent in terms of what makes sense and is reasonable, like shared priorities and roadmaps.

We have been struggling a bit with the GitLab setup, but that's more of a custom solution problem.

Their licensing model is fairly robust and scalable for our needs. I believe we have reached a reasonable agreement on the licensing to enable hundreds of developers to participate in this product offering. The solution is very tailored towards developers and its licensing model works well for us.

It addresses a lot of needs, especially in growing organizations. The more developers, the more heterogeneous your environment will look, as well as needing more tools to help you scale security practices. In this regard, it seems to be a very promising, scalable solution.

We have been utilizing the solution’s container security feature. It is not at full scale, though. We are engaging Snyk on container integrations.

I would rate it an eight (out of 10).

I use the tool in my company to scan open-source projects.

I don't use Snyk anymore. The tool is just used in our company, but not by me anymore.

It is important that the solution has the ability to match up with the OWASP Top 10 list, especially considering that sometimes, it cannot fix certain issues. Users might face 100 vulnerabilities during the production phase, and they may not be able to fix them all. Different companies have different levels of risk appetite. In a highly regulated industry, users of the product should be able to fix all the vulnerabilities, especially the internal ones. The tool should provide more flexibility and guidance to help us fix the top vulnerabilities before we go into production.

I have been using Snyk for three years. I am a user of the tool.

The solution's technical support is okay. I rate the technical support an eight out of ten.

Positive

The product's price is okay. My company isn't actively looking for replacement tools.

The most effective feature in securing project dependencies stems from its ability to highlight security vulnerabilities.

The integration features of the product are okay.

I recommend the product to those who want to buy it.

In a general sense, Snyk is a good product that can be used for governance. If you use a lot of open-source software, Snyk is an application testing tool you can buy.

I rate the tool a seven to 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. 

The product helps me with security vulnerability detection. 

I am impressed with the product's security vulnerability detection. My peers in security are praising the tool for its accuracy in detecting security vulnerabilities. The product is very easy to onboard. It doesn't require a lot of preparation or prerequisites. It's a bit of a plug-and-play as long as you're using a package manager or, for example, you are using a GitHub repository. And that is an advantage for this tool because developers don't want to add more tools to their current use.

The tool needs improvement in license compliance. I would like to see the integration of better policy management in the product's future release. When it comes to the organization I work for, there are a lot of business units since we are a group of companies. Each of these companies has its specific requirements and its own appetite for risk. This should be able to reflect in flexible policies. We need to be able to configure policies that can be adjusted later or overridden by the business unit that is using the product. 

We haven't had big issues in terms of the product's stability. 

The product is scalable. In our company, we have a lot of tools that are used for product and software development. We have been able to onboard them and scale up. However, I have to say that when it comes to displaying a dashboard at the organizational level to see all the vulnerabilities, it takes a bit of time to load, which is annoying.

The product has a fantastic tech support team. We actually have a Slack channel with them, and the customer success managers are a click away from providing us with the latest functionalities and updates if there are any interruptions to the service. So there has always been a transparent dialogue between us; we see them as partners in this journey.

Positive

I wasn't involved in the tool's setup, but from my experience or the experience of my colleagues, the process was positive. I didn't hear them have any horror stories from the days when they set it up.

The solution is less expensive than Black Duck.

I would rate the product a seven out of ten. Snyk is a fantastic tool for security vulnerability detection in third-party open-source software. You can use this product if your focus is on security vulnerability. On the other hand, if you don't want your developers to invest too much time in documentation and reading white papers on configuring the tool to work for them, you need to use this product. 

I would give them extra points for the transparent communication with the customer and their openness towards improving their product. And I think they have a lot of potential to improve and become a great SCA tool.

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

We use Snyk for the generation of SBOM for Docker. We use it to check the standards of the CSI benchmark that we have implemented in the containers and the applications by Java Spring Boot.

The most valuable feature of Snyk is the SBOM.

It would be helpful if we get a recommendation while doing the scan about the necessary things we need to implement after identifying the vulnerabilities. In short, it will be a remediation for the vulnerabilities identified by Snyk.

I have been using Snyk for two years.

Snyk is a stable solution.

Snyk is a scalable solution. As we are an R&D organization, I am the only person managing the solution. However, there are almost 500 employees who are taking advantage of the report we have generated from the Snyk app.

The solution is easy to use and implement.

The deployment steps were easy. The solution's documentation is also easy to use. It took hardly one and a half hours to implement the solution. We implemented Snyk in our virtual private server (VPS).

For deployment, we followed the instructions and created a server for Snyk. Then, we integrated the server with the plug-in using Jenkins. We created a server for Snyk, then used the GitHub repository that mentioned the document and implemented the same. Later, we used the plug-in to connect the server to the Jenkins server.

When the pipeline was built, the process started, as we had mentioned the stage in the Jenkins file, to generate SBOMs and check whether the Docker images were compliant with CSI Benchmarks.

Snyk is an expensive solution.

Before choosing Snyk, we evaluated a different tool named Dependency-Track. We chose Snyk because Dependency-Track only helped us identify the vulnerabilities in the libraries, and it couldn't solve the issues mentioned in the CIS benchmark.

Snyk helped us identify the composition or the libraries we used in the project, which were vulnerable. It also helped us identify the license agreements from the vendor side.

Software conversion analysis is a mandatory thing that should be implemented in every organization. Most libraries or any third-party libraries are not considered under VAPT. We should also look after the composition of the libraries we use in the project. We should look after these libraries for vulnerabilities, and VAPT should be mandatory in every organization.

I rate Snyk a nine out of ten for the user-friendliness of its user interface.

Currently, my team is looking into whether version numbers are vulnerable. We are also considering the improvisations or research and development we need to do if we need the same library. There are some loopholes that even Snyk has not identified or that it might be working on. Since we have implemented it, we are looking after it.

If a developer requires a particular library with vulnerabilities, we check whether we are using the functions mentioned in the libraries in the project. If we are using it, we are trying to identify exactly which snippet is causing the error. If it is causing a vulnerability, we are considering how to improve it.

We need to think about the decisions we need to make after SCA. It would be a big relief for our organization if Snyk could provide a solution to identify the library snippet that is causing a future vulnerability. We are currently using a team of 30 people to identify this issue.

Overall, I rate Snyk an eight out of ten.