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?


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 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 which appears 
>> similar but is basically a pay service based on node.js. 
>> Also 
>> 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 <> 
>> 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 view this discussion on the web visit

Reply via email to