What advice do you have for others considering Snyk?

Snyk is optimal for organizations starting or looking for an affordable, effective tool. Despite false positives, it combines SAST, SCA, containers, and IaS in one Web UI. On a scale of one to ten, I rate Snyk at six.

Based on our experience and what I have heard internally, I would recommend Snyk. I'd rate the solution nine out fo ten.

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.

The most effective feature in securing project dependencies stems from its ability to highlight security vulnerabilities. The integration features of the product are okay. I recommend the product to those who want to buy it. In a general sense, Snyk is a good product that can be used for governance. If you use a lot of open-source software, Snyk is an application testing tool you can buy. I rate the tool a seven to eight out of ten.

The solution has improved or streamlined our process a lot for securing container images. We wanted to make sure we are deploying the secure Docker images. Snyk allowed us to check whether it is following our standard of docker images or not. We use Azure DevOps as our platform, and Snyk's integration with Azure DevOps was okay. However, Snyk's integration with JFrog Artifactory didn't go well. We use JFrog Artifactory to store the artifacts we download. We wanted to integrate Snyk with JFrog Artifactory to scan the binary artifacts we downloaded, but that broke our JFrog Artifactory for some reason. Instead of using it there, we are calling it directly from the pipeline. Snyk's automation features significantly reduced remediation times a couple of times. Sometimes, our developers scan the code from the environment and find some Java vulnerabilities. We fixed those vulnerabilities in the lower environment itself. The solution does not require any maintenance. The accuracy of Snyk's vulnerability detection is pretty good compared to other tools. I rate the solution's vulnerability detection feature an eight out of ten. I would recommend Snyk to other users because it is easy to implement and integrate with Azure DevOps and GitHub. Overall, I rate the solution a seven out of ten.

Snyk helped us identify the composition or the libraries we used in the project, which were vulnerable. It also helped us identify the license agreements from the vendor side. Software conversion analysis is a mandatory thing that should be implemented in every organization. Most libraries or any third-party libraries are not considered under VAPT. We should also look after the composition of the libraries we use in the project. We should look after these libraries for vulnerabilities, and VAPT should be mandatory in every organization. I rate Snyk a nine out of ten for the user-friendliness of its user interface. Currently, my team is looking into whether version numbers are vulnerable. We are also considering the improvisations or research and development we need to do if we need the same library. There are some loopholes that even Snyk has not identified or that it might be working on. Since we have implemented it, we are looking after it. If a developer requires a particular library with vulnerabilities, we check whether we are using the functions mentioned in the libraries in the project. If we are using it, we are trying to identify exactly which snippet is causing the error. If it is causing a vulnerability, we are considering how to improve it. We need to think about the decisions we need to make after SCA. It would be a big relief for our organization if Snyk could provide a solution to identify the library snippet that is causing a future vulnerability. We are currently using a team of 30 people to identify this issue. Overall, I rate Snyk an eight out of ten.

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.

I rate the product an eight out of ten.

The major reason why customers prefer Snyk is that, nowadays, people are moving towards cloud-native tools. People also want a tool that offers safety and security, especially during the integration process and during the coding part. Snyk offers a set of much better features when compared to other tools like SonarQube or Veracode. Smaller companies can choose the team plan or enterprise version offered by Snyk. The major reason why people prefer Snyk is because of the security it offers. I rate the overall tool a six or seven out of ten.

I recommend Snyk to others and rate it a seven out of ten.

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 rate Snyk seven out of 10.

Snyk is a cloud product. AWS is the cloud provider for Snyk. People should consider using the scalable model of Snyk for SCA before considering other tools. If you are in the initial security phase or newly setting it up for practice in your organization, I recommend starting with Snyk. Anyone starting into the market and not wanting to invest in a large amount should consider Snyk as an alternative. Snyk is a good tool that provides equivalent security standards compared to other expensive tools. I've seen the evolution of Snyk in the last four to five years. They started with software composition analysis and have now integrated static application security testing. They have partnerships with various dynamic security testing companies like StackHawk, Rapid7, and InsightAppSec. Snyk is progressive, and they have a good R&D team. I work for a service-based organization, where my job is to understand the customer's pain points and provide consultation. Most customers' pain points are the trade-off between cost and security compliance. Most customers come with financial constraints, and at least a few are opting for Snyk as an option because they were able to get the desired results. And Snyk is doing a pretty good job concerning the standard these customers need to extend to their partners. Overall, I rate Snyk an eight out of ten.

Upon reviewing Snyk's operations, I found it helpful, although not entirely comprehensive. Specifically, it provides valuable information regarding the status of vulnerabilities and the details of dependencies used in our projects. The solution also can identify issues that could be resolved manually or through alternative means. Snyk gives all the required information, while SonarQube doesn't. In SonarQube, data is presented in a different format that is required to be reviewed by us on a line-by-line basis. One of Snyk's strengths was its ability to consolidate all identified issues into a single location. Currently, our company has not utilized any expensive solutions. So, we opted for SonarQube's open-source version. In the future, if the need arises, we may consider purchasing a solution. However, as this is for a proof-of-concept (POC), I am currently exploring trial or open-source versions, which are free of cost. If a solution is successfully integrated into our projects and our developers become familiar, we may consider purchasing a particular solution. For now, we are focusing on finding a solution that meets our needs for the POC without incurring any unnecessary expenses. I would definitely recommend the solution to those planning to use it. Overall, I rate the solution a seven and a half out of ten. To be more specific, I would rate it an eight out of ten.

I would rate the product a seven out of ten. Snyk is a fantastic tool for security vulnerability detection in third-party open-source software. You can use this product if your focus is on security vulnerability. On the other hand, if you don't want your developers to invest too much time in documentation and reading white papers on configuring the tool to work for them, you need to use this product. I would give them extra points for the transparent communication with the customer and their openness towards improving their product. And I think they have a lot of potential to improve and become a great SCA tool.

I would recommend people use the free tier first before they purchase. I rate Snyk a ten out of ten.

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

I rate the solution a nine out of ten.

I would rate it a seven out of ten.

Overall, Snyk is a satisfactory solution that I believe could be improved by reducing the number of false positives and extending coverage for more languages and frameworks. I would rate Snyk a seven out of ten.

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

I rate Snyk an eight out of ten.

I would rate it a seven out of ten.

Snyk is good. I like to use it. I like to use Snyk over Contrast. On a scale of one to ten, I would give Snyk an eight. There is no complaint here.

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.

I have been using this solution for one and a half years, and I definitely like it. It is awesome in whatever it does right now. It is a really nice tool if you really want to do the dependency check and security scanning of your code, which falls under static code analysis. You can implement it and go for it for static code analysis, but when it comes to dynamic, interactive, and run-time scanning, you should look for other tools available in the market. These are the only things that are missing in this solution. If it had these features, we would have gone with it because we have already been using it for one and a half years. Now, the time has come where we are looking for new features, but they are not there. Considering the huge database they have, all the binaries it scans, and other features, I would rate Snyk an eight out of 10.

I have heard from my team that it has a comprehensive database. Hopefully, it will work well during the production usage. Our hopes are high. So far, we haven't seen any downsides. We have our internal processes for maintaining and updating dependencies in general. We will be incorporating any suggested updates coming from Snyk into our internal, already-existing process and platform, with some additional effort from our teams. Hopefully, there won't be any major additional effort. Hopefully, cases needing additional effort for issues will be rare. We are using the SAST version of Snyk. Its complexity is reasonable. I would rate it as an eight out of 10.

If you're going to be doing any sort of software development that involves open source software, like many people do, many people have a blind spot or don't have a tool like this to even understand the risk that they take by pulling in an open source. It's not to say open source is bad, it just has a new threat surface that you have to monitor. We get a lot of benefit out of monitoring it, so I think ultimately we see problems others don't and have the opportunity to fix them. Therefore, there is a good chance that we will have fewer issues, like unauthorized data access, where they are sort of significant events because we have the visibility and the means to rectify them. Snyk's actionable advice about container vulnerabilities is pretty good. I would rate it a six (out of 10). It's a newer offering for them, so it doesn't have the completeness of vision that their software composition analysis has, but it still appears to be accurate. It's a different type of product. They haven't packaged it to be very actionable, e.g., just do this one thing or here is the next step to fix this. It is a bit more abstract and has an explainer to it. You have to sort of distill that into what you need to do, but it still seems accurate. It is a little bit more to wrap your head around than how easy they have made the software composition product. If you are looking for a software composition analysis product that provides remediation advice and you can't act on the details it's going to give you, you might be just as good dealing with a little bit less full featured product. However, if you want to be proactive as well as have the capability and technical resources that can move on the recommendations that Snyk makes, then you can realize a significant value out of this product. Thus, if you are at the level of maturity that can appreciate what this product can provide, it is a great value. I would rate this solution a nine (out of 10).

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.

My advice is just try it. If you've got a modern development pipeline, it's really easy to wire up, if you've got somebody with the right skills to do that. We found with a development community, it's really easy to build these things. Get on with it and try it. It's really easy to trial and see what it's telling you about. That's one of the great upsides of that model: Play with it, convince yourself it's worth it, and then talk to them about buying it. It's hard to judge Snyk's vulnerability database in terms of comprehensiveness and accuracy. It clearly is telling us a lot of information. I have no reason to doubt that it is very good, but I can't categorically back that up with my own empirical evidence. But I trust them. I don't get the sense there are many false positives from Snyk, and that's a very positive thing. When it tells us something, it's almost certainly a real issue, or at least that a real issue has been found somewhere in the open-source world. What is always harder to manage is to know what to do if there is no resolution. If somebody has found a problem, but there is no fix, then we have a much more interesting challenge around evaluation of whether we should do something. Do we remove that library? Do we try and fix it ourselves, or do we just wait? That process is the more complicated one. It's less of a false positive issue and more an issue of a real finding that you can't do anything about easily. That can sometimes leave you ignoring things simply because there's no easy action to take, and that can be slightly dangerous. The solution allows our developers to own security for the applications and the containers they run in the cloud, although that's still something we're working on. It's always a challenge to get security to be something that is owned by developers. The DevOps world puts a lot of responsibility on developers and we're still working to help them know; to have better processes and understand what they need to be doing. We still have a security oversight function who is trying to keep an eye on things. We're still maturing ourselves, as a team, into DevSecOps. As for Snyk's lack of SAST and DAST, that's just another one of the tools in the toolkit. We do a lot of our own security scanning for application-level or platform-level attacks. We have pen tests. So the static application is not something that we've seen as particularly important, at this point. Snyk is an eight out of 10. It's not perfect. There are little things that could clearly be improved. They're working on it as a company. They're really engaged. But the base offering is really good. We could also use it better than we are at the moment, but it's well worth it. It's brilliant. The biggest lesson I have learned from using this solution is that there is a big gap between thinking your software is safe and knowing what the risks are. Information is power. You don't have to take action, but at least you are informed and can make a considered judgment if you take it seriously. That is what Snyk really provides. The ethos of Snyk as a company is really positive. They're keen to engage with customers and do something in a slightly different way, and that younger, hungrier, more engaged supplier is really nice to work with. They're very positive, which is good.

Make sure you know how you want to structure the product at the time that deploy it, because it's hard to go back and restructure it. Prepare a deployment plan before you implement it. Snyk reports vulnerabilities and alerts on vulnerable libraries, but there are usually a lot of stipulations on if it will be a vulnerability within the code. For example, it might say, "This library is vulnerable, but only if you're using these functions." Then, there is kind of a decision: * Is it just going to be easiest to upgrade it and not really investigate it? * Or do you investigate it and figured out if it's a false positive or not? So, it depends on how you define false positive. It alerts on vulnerable libraries, but it also says, "Only if you're doing this with these functions," which a lot of the times the case is not, but requires some investigation. Snyk supports 95 percent of the environment that we have. We do have some code that is not supported by them. We have other solutions to cover SAST and DAST. If Snyk were to come out with these solutions, we would be interested in what they have and possibly adopting those. It's not a concern for us that they don't have those, because we use other solutions to cover SAST and DAST, but we also want to be able to cover vulnerable dependency alerting. They're always coming out with new stuff. I would rate the solution as a nine out of 10.

Check the following before using Snyk: * Your language frameworks and whether Snyk can cover them. * The specific packet managers that your are using. * How Snyk performs with all your platforms, not just the main part. Gauge the difficulty. Check the solution for all your language specifics. We have had some interesting projects where the default configuration does not work. Before using such products, you should check it in the most complex projects that you have. Based on all our products, including Snyk, we have seen a 50 percent reduction in the amount of time it takes to fix problems. The solution allows our developers to spend less time securing applications, increasing their productivity. The feedback: It's a very interesting solution. It is clear what we are using it for and how we should use it. However, if we are talking about the interest from our developers, then the solution was evaluated as a medium. This is because of its readiness for implementation and adoption process. I would rate this solution as an eight or nine out of 10.

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.

Focus initially on setting up a clear path for developers to integrate with the tool. Initially, most developers are not super excited about security tools and scanning in the first place; very few people are. So working on the developer adoption, and showing them what features are available and how that can directly benefit their projects, without their feeling like they have a lot of work to do, would be something that I would suggest for new teams. The biggest lesson I have learned from using Snyk is that just when you think there are all the integrations offered in the world, there's another one. There was someone on our team that asked about an integration that they saw Snyk was offering, but it was only in their SaaS product at that time. The following month we got it in our product. They're coming out with new integrations all the time and improving the existing ones. Those are super helpful for meeting the wide range of needs across our many different teams here. We have it running in our main repositories. We have Snyk continuously running there and scanning every commit that developers issue. We also allow developers to run the tool whenever they would like as well, on their other projects, or just to mess around with it, to get a better feel for it. We use things like TeamCity for our pipeline so we use a lot of Snyk's CLI scanning features to integrate with our tools, because some of our code bases have a little bit of a custom dependency setup. That means we have to do a couple of extra steps to get those to integrate smoothly. Because of our custom workflows, there has been a little bit more manual work. Snyk has a lot of plugins, including a TeamCity plugin, that would be really nice to use out-of-the-box, but because of our more custom setup, we have had to do a little bit more manual work. The nice thing is that Snyk does allow us to still do that. It's not like we can only use exactly what they offer and that's it. Between their plugins and using the CLI, we're able to integrate in pretty much any environment we need. I haven't gone through it to specifically look for false positives. Sometimes it will say there's a vulnerability and we turn out not to use that function or not to use that particular piece of that dependency. Unfortunately, most of the containers we have scanned it against, and the ones that we use, are running an older operating system. Because the operating system is no longer actively supported, there are a lot of packages that need upgrades that we can't upgrade because we're blocked on the operating system upgrade itself. In that regard, we don't have too many actionable items from those scans. It does give us the information we need to understand how to prioritize the upgrade itself, versus upgrading the various vulnerabilities that came out of that scan. When we have used it against some other containers, just to check as more of a one-off, it has come back with useful results. Recently there was one that had four results, and the team I was working with scanned it against multiple other tools as well, tools that they were looking at, and they all reported pretty similar things. That was good news to hear for Snyk, that we were right there and detecting everything correctly and had the same useful output. Snyk's container security feature allows developers to own security for the applications and the containers they run in the cloud. We've been a little slow to get that fully integrated with all of our teams. We've mostly focused on our main application at the moment and I've had limited bandwidth to expand past that. But in general, both the container scanning as well as the other features of Snyk allow our teams to own their own security a little bit more, by the nature of the use of the tool and how easy it is to scan new projects or new container images. There's really nothing blocking our teams from discovering that on their own. I just haven't been able to get around to evangelizing all of the features of Snyk. As for Snyk's lack of SAST and DAST versus the solution’s ease of use for developers, fortunately for us, we have other tools that cover those aspects and we've had those running for a while already, so we haven't really thought of those areas as lacking in Snyk. For us, it's really just been a tool that has been easy to use the whole time. If we were able to integrate more of the SAST portion especially, that would make the whole process a little bit more streamlined and potentially easier to work with. But at the moment, thankfully, we have a couple of workflows already set up for those various needs, things that really compliment each other well.

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.

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

If we find an issue, then we talk to our developers who have a specific amount of days to fix the vulnerability. However, we are not fully using all the features that Snyk provides. While I know they could make a suggestion or do automation to fix issues, we are not using those features. Snyk has really nice features. They take into consideration what customers are telling or suggesting to them. It's a very good product. I would rate it a nine (out of 10).

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.

At first, we were using it only for scanning the images that were getting sent to production. Then, we added the entire workload running on our clusters. This increased our vulnerabilities because there were duplicates, but also gave more visibility. The more you put into learning the tool, the better results you will get. Even if it's easy to use, you do need to create the habit of using it with your DevOps. Once it's integrated, it will be a lot easier. You'll see quickly the issues that you can fix when you're writing your code and don't have to wait until the end of QA to be denied. I don't see anything Snyk can report as a false positive because the vulnerability database is there and the vulnerable code in the package. It just depends on how you invoke the code. Unless they start scanning the code, they cannot know. From that perspective, false positives are pretty low, almost non-existent. Our developers are spending more time working on Snyk issues than before, mainly because they were not aware of things that they needed to fix. The process is easy to fix something, so it neither increases nor decreases our developer productivity. It does require a bit of time, especially when creating the habit of using the tool, but the investment is worth it. It enables developers to own security. If you can get the developers to own security, you are reducing a lot of weight off of your security team. Then, you don't need to have such a big security team because the solution offloads a lot of work. Get the developers on your side. We managed to make it mandatory, but this won't happen everywhere. If a developer takes a solution to heart in a project and really wants to use it, it'll go well. Otherwise, if you keep fighting against them, then it will be a hassle. If Snyk offered a SAST/DAST solution, we would be interested in testing it out. We have good experience with the platform and we could consolidate our efforts with them. We are not super satisfied with our current SAST implementation. What I want for the future is to get more proactive adoption instead of adopting because it is mandatory. Adoption will grow, especially if Snyk have other features coming in. We enjoy the product. I would rate the solution as a 9 (out of 10).

If you're looking for a source composition analysis tool or a tool to monitor your open source security, then it's a fantastic solution. SAST and DAST are very important functions. We have alternative options for those though. I wouldn't say the solution’s lack of SAST and DAST hurts or affects us. It would be nice if these were a platform or offering that they did have. We don't use the solution’s Container security feature at the moment, but we are planning on using it. I would rate this solution as an eight or nine (out of 10).

It saves a lot of my time and the developers' time. Also, because everything is super simple and straightforward in one place, it is really convenient for the security team to keep an eye on vulnerabilities in their projects. Having this type of tool for a security team is really helpful. In my previous role, we didn't have this type of tool for our team. We struggled a lot with how we could enhance our visibility or see our projects: what dependencies they were using and if we could monitor those dependencies for any vulnerabilities. Without the tool, we could be attacked by some random vulnerability which we were not even aware of. Thus, I strongly recommend having this type of tool for a security team. This is integrated with our CI/CD. For Containers, we are still not fully rolled out and working around it. I would rate this solution as a seven (out of 10).

Some of our products are deployed on the private cloud behind firewalls, Snyk has tools to carry out security scanning from our private repositories. For anyone thinking of using the product, I would suggest using cloud and SaaS providers. Generally, they are easy to work with and there's no hassle of having to talk to salespeople and arrange demos, etc. Self-service SaaS products are a good way to go when it's appropriate. I would rate this product a nine out of 10.