Open Source audit of go package dependencies for security vulnerabilities?

[Steve Mynott]

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

[Eric Johnson]

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.

Steve Mynott <steve...@gmail.com>
cv25519/ECF8B611205B447E091246AF959E3D6197190DD5

[Paul Jolly]

Some related discussion in https://github.com/golang/go/issues/24031 and linked issues.

--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CANuZA8RhYQrLY%3DJ_BgqYzJm%3Dehyr%3DbCo1F%3D2pCcJJ8cf2u-Vig%40mail.gmail.com.

[Eric Johnson]

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 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

[Chris Hines]

Have you seen: https://github.com/sonatype-nexus-community/nancy

"A tool to check for vulnerabilities in your Golang dependencies, powered by Sonatype OSS Index"