Snyk Reviews

We are using it to identify security weaknesses and vulnerabilities by performing dependency checks of the source code and Docker images used in our code. We also use it for open-source licensing compliance review. We need to keep an eye on what licenses are attached to the libraries or components that we have in use to ensure we don't have surprises in there.

We are using the standard plan, but we have the container scanning module as well in a hybrid deployment. The cloud solution is used for integration with the source code repository which, in our case, is GitHub. You can add whatever repository you want to be inspected by Snyk and it will identify and recommend solutions for your the identified issues. We are also using it as part of our CI/CD pipelines, in our case it is integrated with Jenkins. 

As the developers work they can run the checks and they can validate if their work meets our expectation or not. Then they can address the potential issues during development, rather than going through the whole process and then being pushed back and told, "Hey, you've got issues in here. This is an old component that is no longer supported," or "It's something that has a vulnerability." From that point of view, it's very valuable.

I'm not a developer, I'm an information security officer, but the false positive rate seems to be pretty good. Generally, when it picks up something, it's there. Snyk is not an antivirus. When it highlights something then there is a problem. Sometimes you can fix it, sometimes you cannot fix it. The good thing is that at least you are aware that there is a potential issue. If it's something serious, you can try to validate, but you can usually validate the issue against other databases by looking at a CVV. You've got enough information to identify if this is a real problem or not. In the vast majority of the cases, if you look at dependency, it's pretty straightforward. It matches the database that is being picked up, and you can have a look at more details.

Generally, security tools don't necessarily end up in increased productivity. What Snyk prevents is the wasting of time or productivity. If you're trying to go back and fix issues that are caused by potential vulnerabilities discovered by a pen test, trying to retrofit security can be quite painful. From that point of view, you may go a little bit slower because it's an extra step, but at the same time, you save time on the overall process and you're saving exposing the company to risks.

As a tool, Snyk allows us to identify areas where we need to improve, and this could be at the vulnerability level if there is a library that has a vulnerability. It also helps us with the licensing compliance, identifying if the new components that have been added to the code meet our company's open source compliance. In those ways it helps us as a company. The overall impact of Snyk depends on the way you use it. To me, it's the users, not Snyk, doing something.

We are a new company. We started roughly three years ago. But we knew security is a very important factor. We work with some very large companies out there. Privacy and security of their data is very important. Security was something that we knew we had to put in place from the beginning, as a way of demonstrating that we take things seriously. And we also satisfy the needs of our investors and clients when it comes to trusting us as a provider.

The dependency checks of the libraries are very valuable, but the licensing part is also very important because, with open source components, licensing can be all over the place. Our project is not an open source project, but we do use quite a lot of open source components and we want to make sure that we don't have surprises in there. That's something that we pay attention to.

The ease of use for developers is quite straightforward. They've got good documentation. It depends on the language that you use for development, but for what we have — Java, JavaScript, Python — it seems to be pretty straightforward.

It also has good integration with CI/CD pipelines. In the past we had it integrated with Concourse and now it's running on Jenkins, so it seems to be quite versatile.

They've recently launched their open source compliance. That's an area that is definitely of interest. The better the capability in that, the better it will be for everyone. There may be room to improve the level of information provided to the developers so they understand exactly why using, say, a GPL license is a potential issue for a company that is not intending to publish its code.

There is potential for improvement in expanding the languages they cover and in integrating with other solutions. SonarQube is something that I'm quite interested in, something that I want to bring into play. I know that Snyk integrates with it, but I don't know how well it integrates. I will have to see.

Generating reports and visibility through reports are definitely things they can do better.

We've been using Snyk for nearly two years.

Generally, the stability of Snyk is fine. From time to time the reporting bits, when you look at them on the cloud, can be a little bit sluggish when you start having quite a bit of information in there. But there have been no major outages when we couldn't use it. I don't know if the sluggishness is internet-related or it's something within Snyk. They are based in the United States and I don't know if the traffic across the pond is causing any of these issues.

It's not something that you constantly use all the time. When you want to commit something, it runs on a schedule. When you put something through the pipeline, it runs. But again, there have been no outages or issues with the stability.

We have had no issues with scalability. We haven't needed to do anything special to address that. So far, we have had no problems.

Usage, in our case, will depend on the number of developers that we have. So unless Snyk develops additional features, something more we can use, and we expand because of those capabilities, I don't see a massive increase in our user base. It's a development-orientated solution with a small number of people, from management, who generally keep an eye on the reports, from a compliance point of view. It all depends on our company. The only impact that will come from Snyk is if it comes out with new features that we would like to implement.

We had some chats with technical support at the beginning. They seemed to be pretty responsive. Generally, you communicate with them on a support chat-group. If you need more, you can have Zoom sessions. But we only speak with them now if one of the devs finds something that doesn't look right. We haven't spoken to them in a long time.

Snyk replaced some potential candidates. We had some people looking at maybe using CoreOS Clair and there were some discussions about what we could use to scan our repository. But we didn't have anything officially in place. In fact, Snyk was one of the first solutions that I put in place as a paid solution for the security of our code.

Security is something that is quite important for us. We take security seriously and it's something that we baked in from the early stages. We try to shift it as far left as possible. Snyk is a result of our organization's approach towards security, rather than vice-versa. It's playing its role alongside our security needs.

In our organization, I ask that things be done and people are doing them, so I wasn't directly involved in the setup. But the installation seemed to be quite straightforward. I don't get pushback from the dev community. My background is more infrastructure, I'm not a developer, so I can't comment how easy it is to bring everything together. But when I worked with my devs, when we migrated from Concourse to Jenkins, it wasn't such a huge undertaking and it didn't cause us too many headaches.

In terms of developer adoption, they have to use it because we asked them to use it. And once it's part of the pipeline; everything that they push through the pipeline goes through Snyk. It was a company decision to go that way.

The initial rollout took about one week. Most of the stuff was already in place. We just migrated from one pipeline provider to another. It was quite straightforward.

We have a bit of a hybrid approach. Some of it was in the cloud, and we haven't touched that. The integration of the container bit, the CLI integration is done on our cloud and it's something we maintain. We tried to use Snyk's recommendations. It has an API that you can call use to run some scans, but their full-feature recommended solution is to use the CLI, using your own instance of Snyk. So we have a container that's running Snyk, and whenever we run the scans we just call on that.

The deployment involved one or two people internally. When it was just GitHub, it was me and one developer. And when it came to infrastructure, it was me with an infra guy. It depends on the level of expertise that you have in-house and how comfortable people are with similar solutions. At the end of the day, to roll up a container image and pull that into your pipeline is quite straightforward. It's not difficult.

We don't do that much maintenance on Snyk. It's integrated. It's running in the background. We only touch it when we need to touch it. It's not like we need dedicated resources for that.

Between 50 and 70 people are using Snyk at a given time in our organization. Most of them are developers. We might have some QAs who look at something.

It hits ROI for us very well in a couple of areas that we want to address: to ensure that we don't have surprises when it comes to vulnerabilities on our dependencies — libraries and images. And from a compliance point of view, we don't want to be in a situation where we're forced to publish code because someone has decided to use libraries that would force us to either publish everything under GPL or put us in a situation where licenses are not compatible and we would have to redo part of the code.

The ROI is one of those things that is difficult to quantify. It's not something where you can say how much money you have saved. But looking at overall cost versus the benefit, it's worth the money.

Time-to-value is a difficult topic because the way that I see it, Snyk is a preventative measure. It's similar to insurance. How much money are you prepared to spend to address a potential risk? By having a solution like Snyk in place, you prevent your company from being an easy target and being exposed. It's not something you can easily quantify, but Snyk falls under the cost of doing business. You want to have something in there because the overall cost and the overall problems will be a lot greater.

Pricing and licensing of Snyk is okay. Their model is based on the number of committers of your source code, which can be a little bit false at times. It can be false because we have some QAs and some BAs, for example, who sometimes go in and add comments. They're not writing code, but they're flagged as committers of the code. That can cause some misunderstanding but we discussed this Snyk and explained the situation. They were quite okay with that. So although the number of people they see in Snyk is slightly higher, they're not holding us with our backs to the wall, saying, "Hey, you're over your license."

The only cost is whatever you run on your cloud. If you deploy the CLI integration and you run Snyk you need to take into account the cost, but it's not huge.

There are a number of other solutions out there that you can use. We looked at Black Duck from Synopsys and CoreOS Clair for containers. I had a bit of a look at WhiteSource. Because we're using open source software, a lot of our devs like the open source ethos. They had different suggestions so we looked at a number of potential use case scenarios. These days, for example, GitHub also allows you to scan your reports for dependencies and vulnerabilities. AWS also has the ability to scan your base images. You can validate different things at different stages. But the main one for moving the security to the left is Snyk.

In terms of the comprehensiveness and accuracy of Snyk's vulnerability database, I looked at that in the past. When I picked Snyk as a solution and was looking at Black Duck and other companies, I knew Snyk had its own database and was doing quite a lot of research in that area. To me it seems to be quite good compared to other solutions, like GitHub or Amazon. I get more out of Snyk. Snyk picks up more, highlights more, than other solutions I've seen.

Both Black Duck and WhiteSource are more established companies but they're probably more expensive. I haven't looked at the overall costs, but as you throw more into them they tend to be more expensive. Snyk meets our requirements.

If your company develops software, and if you are an open source consumer, you need to have something in place. Do your research and find the best solution. For us, Snyk worked. I am involved in a security working group with my counterparts at our investors. We discussed what we're doing and what we are using and I discussed Snyk there. I discussed it with a couple of companies in particular and shared ideas and I recommended that they have a look at Snyk. Snyk is open source. You can take it for a ride and see if you like it. Once you're happy with it, you can move forward.

The biggest lesson I've learned from using Snyk is that it brings in a little bit of discipline in terms of what people can and cannot use. It also highlights the importance of security. It also adds a little bit of structure by surfacing potential issues. That's one of the most important factors. And having something like Snyk means you can validate and you can demonstrate, when meeting your clients and your investors, that you are meeting security needs and concerns.

In terms of the time it takes for developers to find fixed vulnerabilities, it depends on the type of issue. In some cases, for example, if there is an upgrade and there is a new version of the library, Snyk does make recommendations. If Snyk can do something for you it will do it. It can automatically generate a pull request so you can do a library upgrade. If there is something quite straightforward regarding licensing, they'll highlight that for you. But other issues are a little bit more complex. If it's a container image, for example, and there's no immediate image upgrade, maybe you want to do something like upgrade a library within the image. Some things are quite straightforward, and if Snyk can, it recommends it, and it's pretty easy, pretty straightforward. For other situations it will say you can manually upgrade this, but you'll have to do that process on your own.

Snyk's actionable advice when it comes to container vulnerabilities is aligned with the rest of the solution. We were one of the early users of containers. We have had Snyk in place for nearly two years, so when we started, containers were something very new for them. It's definitely better than other solutions which are free. Can it be better? Yes. As always, things can always be improved, but it's more or less on par with what we have on the regular dependency checks that we have on normal libraries as part of the source code.

If you look purely at the source code, we can do it with a SaaS application. You link your GitHub or your code repository with Snyk and, as you commit code, Snyk scans and reports. For containers, we tend to use the integration part of the CI/CD pipeline as well. All the images are passed through and we're using CLI commands to run this. This requires a little bit of extra setup, but once you put it in place it tends to be quite straightforward and doesn't require any additional work. As for allowing developers to own security for the applications and the containers they run in in the cloud, to be honest with you, in a lot of cases, their main focus is on developing the app. The scanning is more on the infra side. When it comes to containers and streamlining the application installation, that usually falls on the infra. They stay on top of that task. We have it integrated and we keep an eye out in case something has been plugged up. I just ask them to make sure it's addressed as soon as possible.

We're using Qualys to do external scans and external assessments. We also do penetration testing. But at the end of the day, you have to look at what you want from a tool. Maybe there are other solutions out there that claim to do a lot more. I'm sure that there are other vendors that can potentially give you a more integrated and better view, but they come with additional costs and additional complications. It all depends on what you want to do and how you want to achieve that. For us, the purpose of Snyk was to look at the vulnerabilities in the code or Docker container images, and to address the licensing aspect. 

Some companies go with individual solutions for every single part. For example, they use Clair to scan just the containers and something else to scan just the code. They have linting tools and other things. We're not just using Snyk. For example, we also have linting tools for code quality. This is not something that Snyk is doing. We're trying to use what is suitable for us.

Snyk protects vulnerabilities in the code as usual, detects abnormal data flow inside the field, and similar tasks.

The specific feature of Snyk that has significantly improved my vulnerability management is its ability to identify vulnerabilities and suggest solutions to fix them. Snyk's automation capabilities streamline my security tasks by scanning code every time I commit.

Snyk's focus on security is a valuable feature. Also, Snyk supports multiple programming languages, which has positively affected my security practices. I use only two or three languages, and when I change the language in a file, it detects it in the same suite.

I find the AI-powered scanning beneficial. Using Snyk's AI-powered scanning, I can detect around ten or twenty errors in my project with about twenty thousand lines of code, so it helps improve my project by identifying a lot of potential vulnerabilities.

I use Snyk alongside Sonar, and Snyk tends to generate a lot of false positives. Improving the overall report quality and reducing false positives would be beneficial.

I don't need additional features; just improving the existing ones would be enough. 

It scans the entire code really fast, and the auto-scan process is done repeatedly.

I would rate the stability of Snyk an eight out of ten.

It detects issues really fast, but it still has a lot of false positives, and sometimes the suggestions aren't quite on point. This can sometimes lead to other vulnerabilities.

I would rate the scalability of Snyk a seven out of ten.

I would rate the initial setup of Snyk a nine out of ten because it's straightforward. The web version is also easy to use. I'm working with both the web version and the IDE at the same time.

For deployment, I just link it to GitHub, upload the repository there and it automatically scans for any errors. It took around a minute to deploy Snyk. 

I'm currently using the free version, which the company offers before buying the full version. So, the price is affordable, especially for an enterprise.

I did evaluate other options before choosing Snyk. I only considered Sonar before Snyk, but I ended up with Snyk because it's faster and more focused on security.

My advice for others considering using Snyk is to rely on it for security issues but still manually review your overall code. It's great for detecting syntax errors but might miss some broader issues, so it's important to do a thorough check yourself.

Based on my experience, I'd rate Snyk an eight overall. Its performance is indeed good.

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.

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.

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.

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 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 use the product mainly for software composition analysis. It is used to identify vulnerabilities in the application plug-ins. If we use Python 3.8, it’ll tell us that the version is outdated and that it has several vulnerabilities. It also helps in threat identification. It also provides infrastructure as code.

Static code analysis is one of the best features of the solution.

The product is very expensive.

I have been using the solution for three years.

The product is stable.

We have around 2000 users. Every developer in the organization has access to it.

The support has improved a lot.

Neutral

We use the SaaS version. The initial setup is easy. We just have to click the buttons.

I do not think that the tool is worth the money. A lot of free tools are available online.

The solution costs half a million dollars per year. It depends on the number of users. If the number of users increases, the cost will increase further.

People who want to use the product must utilize the code analysis on IDE. It would really help a lot of the developers. It performs the shift left concept very well. It is a very good tool, but the pricing is absurd. Overall, I rate the product an eight out of ten.