3 ms·
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 the
by 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 agogithub'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.