And then, it also occurs to me that perhaps I can answer my own question. Taking advantage of three aspects of the ecosystem.
#1) Most open source Go libraries are on GitHub #2) Many (most?) CVEs for open source projects will include a reference back to the project, and these references can be extracted from the cvelist <https://github.com/CVEProject/cvelist> project. #3) GitHub has an API to fetch the language of a GitHub repository. Putting those three together, it might be possible to filter every CVE entry that has a reference to GitHub, then every GitHub project in that list that is implemented in Go, and turn that into a list of vulnerabilities for packages. Then match on those packages. That might generate a short list of projects that have had vulnerabilities. That far more reasonable list could then be augmented by a small amount of open source labor to annotate with the versions known to be vulnerable, when new items appear. >From a completely different direction, the CVE quality team is looking to add more data to CVE entries. Seems like implementation language + package management name as additional data in the CVE record itself might also help address the issue. That would be generalizable to Java, Javascript. Rust, Python, and Go, for starters. Before I send that idea in to the quality WG, does anyone here have a better suggestion? Eric On Tuesday, August 13, 2019 at 9:50:19 PM UTC-7, Eric Johnson wrote: > > It would be great to hear of an answer to this question. I suspect there > isn't one, though. > > The trouble is, one of the first hurdles is to identify Go libraries that > have CVEs against them. It is very easy to find CVEs for the Go standard > library, but I cannot see any easy way to scan the vulnerability databases > for vulnerable projects that happen to be implemented in Go. > > On top of that, for the purposes of dependency scanning, we really only > need to care about those projects implemented in Go that have non-main > packages. The main packages may have vulnerabilities, but those will never > show up in a dependency scan... > > If one can identify that list, then the open source tool to find any > dependent libraries that might have vulnerabilities would be pretty > straightforward. > > Unfortunately, identifying that list is might be really hard. Currently > probably only possible for companies that have a business model that > supports paying people to investigate each and every one of the > vulnerabilities that shows up with a CVE.... > > Maybe someone on this list can think of a great way to filter the CVE > list.... > > Eric. > > On Tuesday, August 13, 2019 at 2:32:55 AM UTC-7, Steve Mynott wrote: >> >> I've been introduced to https://rubysec.com/ which has a database >> which easily integrates with builds to check for known security >> vulnerabilities in third party libraries and was wondering whether >> anything similar exists for go packages? >> >> A quick search finds https://snyk.io/vuln?type=golang which appears >> similar but is basically a pay service based on node.js. >> >> Also https://www.owasp.org/index.php/OWASP_Dependency_Track_Project >> looks interesting but doesn't include go. >> >> Does such an open source version exist for go which is written in go >> and integrates easily with builds? >> >> -- >> Steve Mynott <steve...@gmail.com> >> cv25519/ECF8B611205B447E091246AF959E3D6197190DD5 >> > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/95bd2530-182c-4d0f-8d70-b303bf8b1e9d%40googlegroups.com.
