3 ms·

This is nice but I really hope people don't become complacent with this and rely on GitHub to notify them of such things.

jrochkind1 9y ago
I don't know of any way to keep up with vulnerabilities _except_ an automated system. I use `bundle audit` in ruby-land. I don't know why github's automated system will be worse than anyone elses. What alternative is there? Hoping you notice something on a listserv and realize its' one of your (possibly indirect) dependencies? That does not seem better. Automated monitoring and alert is the way to go. And _everyone_ should _always_ be filing CVE's for their vulnerabilities, to make automated detection so much easier.
- tkadlec 9y ago
  Automated tooling is a must, yes. The riskiest part about relying on ONLY GH's solution (IMO) is the NVD/CVE limitation. I agree, CVE would be _awesome_ in theory. In reality, very few file for CVE's and so the coverage is iffy (~11% of npm package vulns and about ~67% of rubygem vulns https://snyk.io/stateofossecurity/ https://snyk.io/stateofossecurity/). But it goes beyond that. There was a great paper earlier this year (https://arxiv.org/abs/1705.05347 https://arxiv.org/abs/1705.05347) that highlighted many other issues: lag between CVE and NVD (which is where all the useful info comes from), mismatched CPE's, nonexistent CPE's, etc. I would love to see us get to a point where the CVE/NVD was enough, but we're far from it right now.
  - gbrown_ 9y ago
    > The riskiest part about relying on ONLY GH's solution (IMO) is the NVD/CVE limitation. Yup, that is the point I was trying to make.
  - jrochkind1 9y ago
    github's announcement made clear they don't plan to only rely on CVE/NVD database, but yeah, you've got to pick a tool you think is good. I think a great many people at non-large companies are using free tools that I think are unlikely to be better than github's. Or no tool at all.

jrochkind1 9y ago

I don't know of any way to keep up with vulnerabilities _except_ an automated system. I use `bundle audit` in ruby-land. I don't know why github's automated system will be worse than anyone elses. What alternative is there? Hoping you notice something on a listserv and realize its' one of your (possibly indirect) dependencies? That does not seem better. Automated monitoring and alert is the way to go. And _everyone_ should _always_ be filing CVE's for their vulnerabilities, to make automated detection so much easier.

tkadlec 9y ago
Automated tooling is a must, yes. The riskiest part about relying on ONLY GH's solution (IMO) is the NVD/CVE limitation. I agree, CVE would be _awesome_ in theory. In reality, very few file for CVE's and so the coverage is iffy (~11% of npm package vulns and about ~67% of rubygem vulns https://snyk.io/stateofossecurity/ https://snyk.io/stateofossecurity/). But it goes beyond that. There was a great paper earlier this year (https://arxiv.org/abs/1705.05347 https://arxiv.org/abs/1705.05347) that highlighted many other issues: lag between CVE and NVD (which is where all the useful info comes from), mismatched CPE's, nonexistent CPE's, etc. I would love to see us get to a point where the CVE/NVD was enough, but we're far from it right now.
- gbrown_ 9y ago
  > The riskiest part about relying on ONLY GH's solution (IMO) is the NVD/CVE limitation. Yup, that is the point I was trying to make.
- jrochkind1 9y ago
  github's announcement made clear they don't plan to only rely on CVE/NVD database, but yeah, you've got to pick a tool you think is good. I think a great many people at non-large companies are using free tools that I think are unlikely to be better than github's. Or no tool at all.