Snyk's AI Trust Platform empowers developers to innovate securely in AI-driven environments, ensuring rapid and secure software development with enhanced policy governance.
| Type | Title | Date | |
|---|---|---|---|
| Category | Application Security Tools | Jun 29, 2025 | Download |
| Product | Reviews, tips, and advice from real users | Jun 29, 2025 | Download |
| Comparison | Snyk vs SonarQube Server (formerly SonarQube) | Jun 29, 2025 | Download |
| Comparison | Snyk vs Veracode | Jun 29, 2025 | Download |
| Comparison | Snyk vs Checkmarx One | Jun 29, 2025 | Download |
| Title | Rating | Mindshare | Recommending | |
|---|---|---|---|---|
| SonarQube Server (formerly SonarQube) | 4.0 | 23.5% | 81% | 116 interviewsAdd to research |
| Wiz | 4.5 | N/A | 95% | 22 interviewsAdd to research |
Snyk’s platform integrates AI-ready engines across the software development lifecycle, offering broad coverage with high speed and accuracy essential for fast-paced coding environments. AI-driven features include visibility, prioritization, and tailored security policies that enable proactive threat prevention and quick remediation. By focusing on LLM engineering and AI code analysis, Snyk supports secure and productive development processes. The platform's partnerships, including GenAI code assistants, enhance AI application security by addressing new threats and code velocity challenges.
What are the key features of Snyk?Snyk is implemented across industries focusing on agile development and DevSecOps, enhancing software delivery speed and security. It is widely used for continuous monitoring and adherence to security and licensing standards, especially in environments relying on Docker image security and CI/CD pipeline integration.
Snyk was previously known as Fugue.
StartApp, Segment, Skyscanner, DigitalOcean, Comic Relief
We have a lot of code and a lot of microservices and we're using Snyk to test our third-party libraries, all the external dependencies that our code uses, to see if there are any vulnerabilities in the versions we use.
We use their SaaS dashboard, but we do have some internal integrations that are on-prem.
We scan our code and we go through the results on the dashboard and then we ask the teams to upgrade their libraries to mitigate vulnerabilities.
We feel more secure because we do have a way to measure the security and the risk factors of projects. We're able to create action items for the developers to fix. We have the feeling that we can worry less about these kinds of vulnerabilities, which are very critical vulnerabilities, in all the third-party libraries.
The solution has reduced the amount of time it takes to find problems, for sure. Without it, I would have to do things manually: Go to a project, get the list of libraries and the versions, and then search manually, one by one, in Google. It saves a lot of time. It's hard to estimate how much time it saves, but it must be days of work.
It helps us spend less time securing applications and that way it increases productivity. It saves a lot of time in looking for vulnerabilities in our projects. And, of course, it's much more efficient and quick with Snyk. It's saving us a lot of working days, maybe even weeks.
Snyk also helps us to prioritize things, what we need to deal with. For example, it tells us if there is an available online exploit for the vulnerability in a given library. That way, we know that we will want to address this issue first, because maybe some hacker could use the available exploit on us. It also has a pretty new feature, which is Snyk's own risk score from zero to 1,000, and that has also helped to prioritize. Another new feature we haven't tested yet is to see if a function is really in use in the code, which will also help to prioritize. And, of course, the suggested version to upgrade to is really important information for us.
The most valuable feature is that they add a lot of their own information to the vulnerabilities. They describe vulnerabilities and suggest their own mitigations or version upgrades. The information was the winning factor when we compared Snyk to others. This is what gave it more impact.
For us, in the security team, it's pretty easy to use it to look for issues. If we want to look at a specific project, which may be external or more important or it may be more sensitive, we just go to the Snyk dashboard, look for the project, and directly get a list of all the issues, by severity. It also shows if there is a fix available. The filter is pretty good and we are able to get action items pretty immediately for the developers.
The solution's vulnerability database, in terms of comprehensiveness and accuracy, is very high-level. As far as I know, it's the best among their competitors.
Also, I don't think there are false positives. Even if there is a vulnerable library that is in use, but maybe we're not using the function itself, it's not telling us that we do use that function. There isn't much of a false positive issue.
We tried to integrate it into our software development environment but it went really badly. It took a lot of time and prevented the developers from using the IDE. Eventually, we didn't use it in the development area.
If the plugin for our IDE worked for us, it might help developers find and fix vulnerabilities quickly. But because it's hard to get the developers to use the tool itself, the cloud tool, it's more that we in the security team find the issues and give them to them.
I would like to see better integrations to help the developers get along better with the tool. And the plugin for the IDE is not so good. This is something we would like to have, but currently we can't use it.
Also, the API could be better by enabling us to get more useful information through it, or do more actions from the API.
Another disadvantage is that a scan during CI is pretty slow. It almost doubles our build time.
I have been using Snyk for about two years.
I have never experienced any instability in the solution. It's pretty good.
Their technical support is pretty good. We have a customer success manager. His name is Eliran and he's really nice. He helps us sometimes with actual support, but at other times he helps us with figuring out how to work with Snyk, or how to continue and expand with it.
Before Snyk we used one of its competitors, WhiteSource. We switched to Snyk because we were near the end of our WhiteSource license and we wanted to look at other options. We looked at the competitors and we saw that Snyk has a lot more valuable information on issues, such as exploitability online, and the suggested fixes for libraries, and there were more features. All of this information is very valuable for us, and WhiteSource was lacking it.
The initial setup wasn't too complex. They have good documentation, and it's pretty easy. Because our code repository and ticketing system are internal, we had to set up some Dockers to help us with that, but that also wasn't too hard.
The first deployment, until we started scanning the first project, took less than a week. To get it fully working as we expected, exactly how we wanted it, took some more time. That took some months. But the initial setup was really just a few days.
The implementation strategy was that we first wanted to scan the integration with our internal Bitbucket, the code repository, and get Snyk to scan all of the repositories on a daily basis. We had some struggles at first. We wanted to add the developers as users, so they could use the dashboard, but that didn't work so well. So we used a JIRA integration for ticketing and wrote some scripts that use the API to get some information and create tables with action items. Also, we wanted to add it to our CI so that every time a project was being built, a scan would start and the developer would get the information at that moment.
Right now, we're writing an automation to automatically open JIRA tickets with information from Snyk, for the teams. Hopefully, that will make my job more efficient, and even decrease the amount of work I need to do.
If maintenance is required it's on me, but I really only update our Dockers from time to time. There isn't too much maintenance.
I did it almost all by myself, but we did use Snyk from time to time. I would send them some logs if we had a problem and they would review then and respond with an answer in a few days.
We don't have numbers that say we saved this or that amount because of Snyk, but we have seen ROI. The time I would spend on those kinds of vulnerabilities without Snyk would cost more than what it costs us.
The time to value was pretty much from the beginning; maybe one month or two.
We also looked at Black Duck and SourceClear. The difference between them and Snyk, as with WhiteSource, was the information. The Snyk dashboard was also more user-friendly and more informative. Back then, it looked more user-friendly for the developers, to get them using it. That didn't happen ultimately for us, but it did look that way at the beginning. Their added information was the main trigger.
If you're on-cloud it's pretty easy. If you're on-prem I'd suggest you look carefully at how the integrations should be. I spent some time configuring the Docker because I didn't have the right information, from our side. It would be good to know better the infrastructure and how the source code or ticketing system works before starting to implement the internal Dockers. But if it's on-cloud and you are only using the SaaS dashboard, it's pretty easy.
It is easy to use, but it's hard to get the developers to use it. That part is not too easy. Our developers are not that into it. We, the security team, have to do a lot of manual work ourselves. We have to do a lot of triaging ourselves and then ask the developer teams to take action. I don't think the developer reluctance is something in the tool; I don't think it's the tool's fault. The subject itself is not that appealing to developers and they don't like to take care of security much. It's hard to get them to use it.
Only our security team of three people uses the Snyk dashboard itself. Unfortunately, no developers are using it. I use it on a weekly basis. On the security side, the adoption is high. And the developers always follow my instructions based on the Snyk results that I send to them. If you include the developers who are using my recommendations, then there are dozens of developers "using" it.
I don't think it has reduced the amount of time it takes to fix problems, because ultimately it just tells us to upgrade to a specific version. If we got this information manually, without Snyk, we would still just need to upgrade to that specific version. It's still on the developer side to make the fix. I don't think Snyk is important for that part.
The lack of SAST and DAST in the solution didn't affect our decision to go with Snyk because we see the solution as another aspect of security. I don't know if they should go to SAST or DAST because they are really good at what they do. The product is very good for this kind of security.
Overall, it's hard to say if it has greatly helped our security. It's hard to measure it. I can't say that we had an actual exploitable section in our site that was fixed with Snyk. It's just that we feel way more secure now. The added information they provide is very valuable and helps us prioritize. Prioritization is the most valuable thing we have gotten from Snyk.
