Snyk Reviews

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

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

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

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

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

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

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

I rate the technical support a ten out of ten.

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

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

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

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

The deployment process for Snyk takes like a week.

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

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

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

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

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

I am using Snyk for DevOps and security.

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

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

I have been using Snyk for a few months.

The stability of Snyk is good.

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

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

I have not used a testing solution prior to Snyk.

The initial setup of Snyk was easy.

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

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

I rate Snyk a ten out of ten.

The solution is set up in a test lab for proof of concept on the ACIA component. Our client is proposing the solution in an RFP response that will include 3,000 users when awarded. 

The solution has great features and is quite stable. 

The log export function could be easier when shipping logs to other platforms such as Splunk. 

I have been using the solution for months.

The stability is quite good. 

The solution is scalable with no issues. 

I have not needed technical support. 

The initial setup is quite straightforward and took fifteen minutes. 

We implemented the solution in-house. 

In our lab environment, the deployment strategy is to install and run with no complex operations. 

I rate the solution a nine out of ten. 

We use this product for security analysis. It enables us to analyze the development code and find the security vulnerabilities and best practices. We have around 20 developers testing this solution. I'm the senior DevOps and we are users of Snyk.

The solution is very easy to install. It provides clear information and is easy to follow. We get good feedback regarding code practices and how to fix security issues. Another benefit is that it has worked with containers for a long time and has a partnership with Docker. They have a lot of experience and good expertise in security.

I think they could improve the feature for automatic fixing of security breaches. If they had a Kubernetes coverage of vulnerabilities that would be helpful.

I've been using this solution for two months. 

The solution is stable. 

The solution is scalable. 

The technical support is good. They are very helpful and also offered us a demo.  

The initial setup is not complicated, it's just configuring the connection, and connecting to the server.

We're using the open source version for now.

I think it's worthwhile to try this product and I rate it nine out of 10. 

I am a reseller. We provide solutions for our customers.

It's a good product. I haven't seen any weakness.

Snyk is a developer-friendly product.

Compatibility with other products would be great.

I have not contacted technical support.

Previously, I was working with Micro Focus Fortify.

The initial setup is easy.

We have also evaluated Prisma Cloud by Palo Alto.

We tried to partner up with Snyk, but we were not successful in gaining a partnership. We are not authorized Snyk resellers.

I would rate Snyk an eight out of ten.

We use Fugue to gain better visibility. It enhances the ability of Kubernetes operational management within the Azure platform. We use it to extend, monitor, and operationally manage the capabilities of Kubernetes' workloads.

Gain visibility and fine-grained monitoring capabilities for complex Kubernetes environment

Fugue provides core capabilities that enable visualization, discovery, and compliance automation.

These Fugue capabilities are delivered as software as service and were easy to consume.

Combined with Slalom’s advisory, solution integration, and cybersecurity services, Fugue was straightforward to implement and deploy.

It would be ideal if there was customization with a focus on specific cybersecurity areas or capabilities. Fugue is cybersecurity, an operational monitoring solution, which has a broad set of capabilities. However, one needs to have substantial know-how in the cybersecurity domain to be able to identify and zero in on specific Fugue capabilities that may be relevant to a particular project or workstream pursuit. 

Being a system integrator, for us, it isn't an issue. For a client that is new to Fugue or relatively new to cybersecurity, it would be quite challenging to zero in on a specific sweet spot or capability.

I've been using the solution for about eight months to a year at this point. We have multiple teams in our organization that use the solution for various periods of time.

We've been impressed with the stability fo the solution. It doesn't crash or freeze. It's not glitchy. It's reliable.

The scalability is excellent and hasn't let us down. If a company needs to expand the solution, they can do so with relative ease.

Currently, in our organization, about 100 people actively use it.

The solution's technical support is quite good. We have a model of Alliance partnerships. We have well defined and well-orchestrated working relationship with Fugue, being a system integrator and partner. It works well.

we use Fugue and Alcide to extend and augment existing 'native features' of azure

The solution's initial setup wasn't complex at all. It was pretty straightforward.

We're an integrator and reseller. We handle implementations for clients.

I'm unsure of the costs associated with the solution.

We used Fugue in combination with Alcide.io

We're a Fugue partner.

In terms of which version we are using, I would have to say that it was the latest one that we worked with. The exact number version escapes me. I would have to go back and check. 

The solution was specifically deployed to assist with cloud management of Azure in a specific case, however, we are using it across all of the cloud supply platforms including Google Cloud and AWS.

I would absolutely recommend this solution to others.

Overall, I would rate the solution at an eight out of ten. It works well, however, a user needs to be fairly knowledgable in cybersecurity in order to get the most use out of it.

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.

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.

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