4 ms·
> With your dependency graph enabled, we’ll now notify you when we detect a vulnerability in one of your dependencies and suggest known fixes from the GitHub co
by solatic 9y ago
> With your dependency graph enabled, we’ll now notify you when we detect a vulnerability in one of your dependencies and suggest known fixes from the GitHub community.
Why not go one step further and automatically open a pull request fixing the issue? If you can build a model of the dependency graph, then changing the version to an up-to-date version should be trivial.
Of course, there's no guarantee that the commit in the pull request will successfully build, and you'd still need a project maintainer to fix issues in the build caused by the version change. But the data you get is invaluable. If the security alert is unfixable (from the project maintainer's perspective, since upstream hasn't released a fix yet), then why are you alerting a maintainer about something unfixable? If the proposed fix's build is green, then the alert should have a "higher volume" (so to speak), and if the proposed fix's build is red, then the "volume" of the alert should be turned down so that the team can focus on fixing the build so that the security patch should be applied.
- theflow 9y agoWe do exactly that at Depfu (for Ruby): https://depfu.com/blog/2017/09/28/depfu-now-flags-security-updates https://depfu.com/blog/2017/09/28/depfu-now-flags-security-u... But I'm also pretty sure Github is going to do that soon, it's an obvious next step.
- irishsultan 9y ago> If the security alert is unfixable (from the project maintainer's perspective, since upstream hasn't released a fix yet), then why are you alerting a maintainer about something unfixable? Sometimes a vulnerability in a dependency doesn't affect you, because you're not using that feature, in other cases the issue does affect you but it's possible to work around it. For the latter case there isn't necessarily a patch that can be generated automatically.