What needs improvement with Snyk?

Snyk has several limitations, including issues with Gradle, NPM, and Xcode, and trouble with AutoPR. It lacks the ability to select branches on its Web UI, forcing users to rely on CLI or CI/CD for that functionality. These limitations were documented in a book that I wrote.

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

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.

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

The solution's integration with JFrog Artifactory could be improved.

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

The product is very expensive.

The tool's initial use is complex.

I think Snyk should add more of a vulnerability protection feature in the tool since it is an area where it lacks. Snyk needs to focus on the area related to dependencies.

Snyk's API and UI features could work better in terms of speed. Additionally, they could optimize and provide better reports, including reports for security, technical, and developer level.

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

Sometimes we have problems upgrading a library because it's too old. The only thing we can do is use another library.

Snyk can be improved on the reporting aspect regarding the traceability of SCA. It also doesn't have storage. For instance, if you are scanning version 'X' and then you're scanning on another version 'X+1', it doesn't store your information. It doesn't compare particular vulnerabilities between 'X' and 'X+1'. Snyk is helpful and quite handy for people on the development team. The solution's reporting and storage could be improved. The next release of Snyk should have more training features for developers. The tool offers software composition analysis, and though it says what needs to be fixed, it's in a reactive space. Since DevSecOps has become a culture nowadays, and the industry is going more towards proactive measures, the developers need to be trained.

One area where Snyk could improve is in providing developers with the line where the error occurs.

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

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

It was good, but we had a few limitations with it. We were mostly using containerized applications. We were using Microsoft Docker images. It was reporting some vulnerabilities, but we were not able to figure out the fix for them. It was reporting some vulnerabilities in the Docker images given by Microsoft, which were out of our control. That was the only limitation. Otherwise, it was good.

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

I had a list of what they can improve, and I did share that with them. They are coming up with a beta version. It can be improved from the reporting perspective and scanning perspective. They can also improve it on the UI front. When we started the PoC five months ago, we encountered all these things. So, I asked them to improve on them. They have come up with a lot of new features, but they are still lacking on the UI front and the reporting side of things. If you go to the UI front of Snyk, you won't find it so friendly. Another one is that you can't see the projects clearly. It gets all the sources from the repository. It pulls all the projects from the repository and creates a new project altogether for every new addition. So, you can't group them clearly. For example, if I have one product with different repositories, it creates a number of projects underneath in the Snyk UI. When it comes to reporting, if I run a scan on a particular project, I want the report only for that particular project in a PDF format that I can share with others. Currently, you get the notification over an email with all the projects but not in detail. You have to go to Snyk to find the details of a particular project. You only get a generic view, and you don't get a detailed view of a project. You need to go to the tool, export it as a CSV, and then find it, which is ridiculous. With other tools, once the scan is complete, we can just share the report with the development team that is working on that project, but Snyk doesn't let us do that. They still need to work a lot on the reporting structure. It also needs to be improved in terms of interdependencies. When you run a code scan, the code can have interdependencies. If you have found a vulnerable line somewhere, it might lead to other interdependencies. Currently, Snyk doesn't provide you with interdependencies. For example, it doesn't provide you with the best location to do the fix. Checkmarx does that, and after you fix a particular line of code, all the other dependencies are automatically fixed. Snyk doesn't offer that. So, you have to do the fix one by one, which is a tedious task for the development team. It takes a lot of effort. I shared this feedback with them, and they might be working on it. They told me that they'll consider that.

For the areas that they're new in, it's very early stages for them. For example, their expertise is in looking at third-party components and packages, which is their bread-and-butter and what they've been doing for ages, but for newer features such as static analysis I don't think they've got compatibility for all the languages and frameworks yet. That's something I believe will be expanding over time, but I'm not 100% sure when they're going to get to it. Thus, my main concerns for improvement would definitely be greater language and framework coverage, and on a lesser note I would also like to see a reduced number of false positives on their scans. Then there's the issue of their support. It's not very good, to be honest, and it hasn't been the best experience to deal with them. I think they need to develop proper customer success managers when it comes to Service Level Agreements and how they engage with their customers. On the other hand, their technical support is okay as all the technical aspects are essentially all written down and you just have to follow them.

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.

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.

All such tools should definitely improve the signatures in their database. Snyk is pretty new to the industry. They have a pretty good knowledge base, but Veracode is on top because Veracode has been in this business for a pretty long time. They do have a pretty large database of all the findings, and the way that the correlation engine works is superb. Snyk is also pretty good, but it is not as good as Veracode in terms of maintaining a large space of all the historical data of vulnerabilities.

Feature wise, I like it so far. Maybe a little bit early to call, but feature wise, I'm okay with it. It may be a little bit expensive, but otherwise, it is a good tool. I don't have any complaints. Thankfully, I had help in the decision-making and the initial integration. After that, the actual development and ops teams are using it. So if they are facing issues or they have any concerns, I'm not sure about that. Basically the licensing costs are a little bit expensive.

Compatibility with other products would be great.

It would be great if they can include dynamic, interactive, and run-time scanning features. Checkmarx and Veracode provide dynamic, interactive, and run-time scanning, but Snyk doesn't do that. That's the reason there is more inclination towards Veracode, Checkmarx, or AppScan. These are a few tools available in the market that do all four types of scanning: static, dynamic, interactive, and run-time. We have to integrate with their database, which means we need to send our entire code to them to scan, and they send us the report. A company working in the financial domain usually won't like to share its code or any information outside its network with any third-party provider. Such companies try to build the system in-house, and their enterprise-level licensing cost is really huge. There is also an overhead of updating the vulnerability database.

We would like to have upfront knowledge on how easy it should be to just pull in an upgraded dependency, e.g., even introduce full automation for dependencies supposed to have no impact on the business side of things. Therefore, we would like some output when you get the report with the dependencies. We want to get additional information on the expected impact of the business code that is using the dependency with the newer version. This probably won't be easy to add, but it would be helpful.

Snyk's ability to help developers find and fix vulnerabilities quickly is pretty good. From a one to 10, it is probably a six or seven. The reason is because they make it very clear how to take the steps, but it's not necessarily in front of the developers. For instance, my role here is security, so I go and look at it all the time to see what is happening. The developer is checking code, then their analysis runs in the pipeline and they have moved on. Therefore, the developers don't necessarily get real-time feedback and take action until someone else reviews it, like me, to know if there is a problem that they need to go address. Snyk does a good job finding applications, but that is not in front of the developers. We are still spending time to make it a priority for them. So, it's not really saving time, e.g., the developers are catching something before it goes into Snyk's pipeline. A criticism I would have of the product is it's very hierarchical. I would rate the container security feature as a seven or eight (out of 10). It lists projects. So, if you have a number of microservices in an enterprise, then you could have pages of findings. Developers will then spend zero time going through the pages of reports to figure out, "Is there something I need to fix?" While it may make sense to list all the projects and issues in these very long lists for completeness, Snyk could do a better job of bubbling up and grouping items, e.g., a higher level dashboard that draws attention to things that are new, the highest priority things, or things trending in the wrong direction. That would make it a lot easier. They don't quite have that yet in container security. One area that I would love to see more coverage of is .NET. We primarily use JavaScript and TypeScript, and Snyk does a great job with those. One of the things that we are doing as a microservices developer is we want to be able to develop in any language that our developers want, which is a unique problem for a tool like this because they specialize. As we grow, we see interest in Python, and while Snyk has some Python coverage that is pretty good, it is not as mature. For other languages, while it's present, it is also not very mature yet. This is an area for improvement because there was a very straightforward way that they integrated everything for Node.js. However, as other languages like Rust and .NET gain popularity, we may just have one very critical service in 200 that uses something else, and I would like to see this same level of attestation across them.

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.

One of the things that I have mentioned in passing is because we have a security team and we have the development team. One of the things that would make the most difference to me is because those two teams work independently of each other. At the moment, if a developer ignores a problem, there's no way that our security team can easily review what has been ignored and make their own determination as to whether that's the right thing to do or not. That dual security team process is something that I'd love to see. Other than that, there is always more work to do around managing the volume of information when you've got thousands of vulnerabilities. Trying to get those down to zero is virtually impossible, either through ignoring them all or through fixing them. That filtering or information management is always going to be something that can be improved.

If they were able to have some kind of SAS static code analysis that integrates with their vulnerability dependency alerting. I think that would work really well. Because a lot of times, only if you have this configuration or if you are using these functions, your code will be vulnerable. The alerts do require some investigation and Snyk could improve the accuracy of their alerting if they were to integrate with the SAS static code analysis. I would like to give further ability to grouping code repositories, in such a way that you could group them by the teams that own them, then produce alerting to those teams. The way that we are seeing it right now, the alerting only goes to a couple of places. I wish we could configure the code to go to different places.

The documentation sometimes is not relevant. It does not cover the latest updates, scanning, and configurations. The documentation for some things is wrong and does not cover some configuration scannings for the multiple project settings. For example, sometimes the code base condition is consistent on multiple modules. It's kept on different frameworks and packet managers. This requires Snyk to configure it with a custom configuration from the scan. From this point of view, the documentation is unclear. We will sometimes open enterprise tickets for them to update it and provide us specific things for the deployment and scanning. There is no feature that scans, duplicates it findings, and puts everything into one thing. The communication could sometimes be better. During the PoC and onboarding processes, we received different suggestions versus what is documented on the official site. For example, we are using Bitbucket as a GitHub system for our code, especially for Snyk configurations. The official web page provides the way to do this plugin configuration. However, if we talk about doing direct connection with our managers from Snyk, they suggested another way.

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.

Because Snyk has so many integrations and so many things it can do, it's hard to really understand all of them and to get that information to each team that needs it. Since I was the one who originally set up Snyk, I have been in charge of evangelizing all the features of it, but that's almost a full-time job, and that's not my entire job. I haven't been able to get all of that information out quite as well as it could be. If there were more self-service, perhaps tutorials or overviews for new teams or developers, so that they could click through and see things themselves, that would help. There is so much in there already that it's easy to get a little bit lost, but thankfully they also have great documentation on pretty much all of the features and plugins, to understand them. So it can be up to the person, depending on how much of a self-starter they are, to see an integration and then go poke around and figure out how to get things working.

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.

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.

The way Snyk notifies if we have an issue, there are a few options: High vulnerability or medium vulnerability. The problem with that is high vulnerabilities are too broad, because there are too many. If you enable notifications, you get a lot of notifications, When you get many notifications, they become irrelevant because they're not specific. I would prefer to have control over the notifications and somehow decide if I want to get only exploitable vulnerabilities or get a specific score for a vulnerability. Right now, we receive too many high vulnerabilities. If we enable notifications, then we just get a lot of spam message. Therefore, we would like some type of filtering system to be built-in for the system to be more precise. The same thing applies to policies when you go to the dashboard: Everything is red. Because of the nature of our third-party library, most of them have high security issues. However, too many are identified. Snyk needs to provide a way to add some granularity so you can decide what is relevant.

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.

• More visibility on the package lifecycle because we are scanning our application at different point (DevOps, Security, QA, Pipeline, Production Env) and all those steps get mixed together in the UI. Therefore, it's hard to see the lifecycle of your package. • Docker base image support was missing (Distroless) but support is increasing. • UI taking some time to load. We have a lot of projects in the tool. Snyk is responsive and they work to fix the pain points we have.

There are some new features that we would like to see added, e.g., more visibility into library usage for the code. Something along the lines where it's doing the identification of where vulnerabilities are used, etc. This would cause them to stand out in the market as a much different platform.

If the Snyk had a SAST or DAST solution, then we could have easily gone with just one vendor rather than buying more tools from other vendors. It would save us time, not having to maintain relationships with other vendors. We would just need to manage with one vendor. From a profitability standpoint, we will always choose the vendor who gives us multiple services. Though, we went ahead with Snyk because it was a strong tool. Snyk needs to support more languages. It's not supporting all our languages, e.g., Sift packages for our iOS applications. They don't support that but are working to build it for us. They are also missing some plugins for IDEs, which is the application that we are using for developers to code. There are a couple of feature request that I have asked from Snyk. For example, I would like Snyk to create a Jira ticket from Slack notifications. We already have Snyk creating a pull request from Slack notifications, so I asked if we could create a Jira ticket as well so we can track the vulnerability.

The product could be improved by including other types of security scanning (e.g. SAST or DAST), which is important. It would also help to include the static analysis specifically to the open-source scanning so we could get an idea of whether a particular library is vulnerable and recognise if we're actually using the vulnerable part of it or not, they do have runtime analysis, but it is a hassle to set up. It would be the same issue in terms of the inclusion of additional features. I think static analysis is really important. A second additional feature would be to add tags to projects, identifying an important project or assigning a project to a particular team. Custom tags would be helpful.