Snyk isn’t great to be honest and neither is Dependabot though I like the latter better.
GitHub is the only company uniquely positioned to fix/profit from the major problem of insecure FOSS toolchains but for whatever reason they are dragging their feet on it.
Features I’d like to see from GH:
- Private package repository. Each package includes metadata and rank based upon if its actively maintained or includes vulns. Being a GitHub Sponsor would be mandatory for all companies using the service.
- License audit: At the click of a button or api request fetch licenses for each dependency listed in your repo’s requirements.txt, gemfile, package.JSON etc. Extra points if it can flag problematic licenses automagically
- Dynamic scanning: They are already offering static scans against source code might as well go a step further
- Automagic secure code checklists: Scan my PR’s code and dependencies then generate
a checklist for my dev teams use case.
- Signed-off Exceptions: Give me the option to configure better notifications and more accountability for Dependabot. If I haven’t addressed a vulnerability then automatically communicate the risk to a reviewer.
- Centralized dashboard: Let me view all vulnerabilities for all repos for my organization in one place
And some people might feel all of that is not GitHub's job. Maybe because they like the tools that are familiar to their technology stack, for better or worse. And maybe GitHub doesn't feel like stepping into that minefield?
Just because you are the core infra provider, does not automatically position you to provide the best security. AWS does not provides the best web or network firewalls, microsoft never had the best AV, so forth and so on.
If security is not your core mission, it is always hard to create a fundamentally good offering. That is at least the less of history of such companies. May be Github surprises, but that is what it is.
Dependabot doesn’t work well for a Fortune 50 company or any company with a large micro services pattern because app sec teams are small. It’s really hard to provide oversight or even counsel a development team if you have no centralized view into whats happening across your organization. That’s one problem but there are others like not keeping updated to the latest versions of languages and frameworks.
Snyk like most security tools lacks perspective that takes business and how product teams work into consideration. I’ve heard good things about their container security tools but their appsec stuff doesnt appear to be worth it (they demoed for us recently). We don’t need yet another tool that offers up vulns in isolation of business context. A high vulnerability is not high if compensating controls and application value aren’t considered. That’s great your tool can be yet something else that bugs my devs come deploy time. Want to be worth it? Snyk should focus on moving security left into sprint planning. If not, then they are fundamentally selling the same tools as Veracode and Synopsys.
It’s a good tool, and from what I can tell, the free version is probably enough for most small teams or sole developers. The main benefit of the paid plans seems to be the scanning on private repos and the unlimited tests for 10+ developers. But like I said, the free plan is plenty to work with.
Until these alerts get better at understanding context of use of a dependency, they're going to remain mostly noise. Regardless, users will obsess over them. As a maintainer, the number of issues that get opened for dependency alerts is just annoying.
No, I don't care about the "low" level vulnerability on a RegExp DDoS possibility of a dependency in my development-time tool that would require a dev to DDoS themselves.
"What is snyk", shoves what looks to be a picture and leaves it at that. Eventually I clicked on it and discovered it's a video. Why not just take 5 minutes to write a quick blurb rather than making people watch a video?
Generally these scanners can have two possible opinions about a dependency: "contains security bug" and "don't know" - they can't prove absence of vulnerabilities. So if tool A flags a dependency and tool B doesn't, both are likely right, and you should treat it as a flagged dependency.
we have this thrust on us ...
we get pull requests for point release updates but it misses entire versions
it decides that packages that have legitimately been forked by a manufacturer should be replaced by the original package because it has a version bump
generally it been a pain in the backside
I was under the impression there’s no scanning as such whatsoever? It just sends a list of your packages and figures out which one should be upgraded based on what they know.
I'm not convinced their tools are better than npm audit + a license checker package, although I suppose it's nice if you want a dashboard that works for many languages instead of just Node.
I've been very disappointed with their PR tools, and ended up turning off their automated PRs on _their suggestion_. (They will create dozens or hundreds of PRs to update dependencies, rather than rewriting them. Dependabot is 100x better to work with.)
They use a different vulnerability database. Snyk's contains vulnerabilities that NPM's doesn't have, and vice versa. We're using them both in combination.
GitHub is the only company uniquely positioned to fix/profit from the major problem of insecure FOSS toolchains but for whatever reason they are dragging their feet on it.
Features I’d like to see from GH:
- Private package repository. Each package includes metadata and rank based upon if its actively maintained or includes vulns. Being a GitHub Sponsor would be mandatory for all companies using the service.
- License audit: At the click of a button or api request fetch licenses for each dependency listed in your repo’s requirements.txt, gemfile, package.JSON etc. Extra points if it can flag problematic licenses automagically
- Dynamic scanning: They are already offering static scans against source code might as well go a step further
- Automagic secure code checklists: Scan my PR’s code and dependencies then generate a checklist for my dev teams use case.
- Signed-off Exceptions: Give me the option to configure better notifications and more accountability for Dependabot. If I haven’t addressed a vulnerability then automatically communicate the risk to a reviewer.
- Centralized dashboard: Let me view all vulnerabilities for all repos for my organization in one place
They have already stepped their foot into application security in a big way.
See: https://github.com/features/security
With a little bit more concentrated effort, they could take major market share from Veracode, Synopsys and every other appsec outfit for lunch.
If security is not your core mission, it is always hard to create a fundamentally good offering. That is at least the less of history of such companies. May be Github surprises, but that is what it is.
Snyk like most security tools lacks perspective that takes business and how product teams work into consideration. I’ve heard good things about their container security tools but their appsec stuff doesnt appear to be worth it (they demoed for us recently). We don’t need yet another tool that offers up vulns in isolation of business context. A high vulnerability is not high if compensating controls and application value aren’t considered. That’s great your tool can be yet something else that bugs my devs come deploy time. Want to be worth it? Snyk should focus on moving security left into sprint planning. If not, then they are fundamentally selling the same tools as Veracode and Synopsys.
https://mailchi.mp/webtoolsweekly/web-tools-394
It’s a good tool, and from what I can tell, the free version is probably enough for most small teams or sole developers. The main benefit of the paid plans seems to be the scanning on private repos and the unlimited tests for 10+ developers. But like I said, the free plan is plenty to work with.
No, I don't care about the "low" level vulnerability on a RegExp DDoS possibility of a dependency in my development-time tool that would require a dev to DDoS themselves.
I've been very disappointed with their PR tools, and ended up turning off their automated PRs on _their suggestion_. (They will create dozens or hundreds of PRs to update dependencies, rather than rewriting them. Dependabot is 100x better to work with.)