search

nexB / vulnerablecode

A free and open vulnerabilities database and the packages they impact. And the tools to aggregate and correlate these vulnerabilities. Sponsored by NLnet https://nlnet.nl/project/vulnerabilitydatabase/ for https://www.aboutcode.org/ Chat at https://gitter.im/aboutcode-org/vulnerablecode Docs at https://vulnerablecode.readthedocs.org/
https://public.vulnerablecode.io
Apache License 2.0
503 stars 184 forks source link

Collect Go vulnerabilities from golang/vulndb #749

Open pombredanne opened 2 years ago

pombredanne commented 2 years ago

See https://github.com/golang/vulndb/blob/master/reports/ This is a follow up from #466

pombredanne commented 7 months ago

There are some issue wrt. Go which is why we did not enable imports from the various datasources that provide Go vulnerability data.

Problem

Go is problematic as when we scan there is no universal way to find when a go package names ends and when a subpath stats. Hence creating a PURL is difficult because it may need to access the whole set of know packages to find what is the namespace/name of a package.

Context

Go vulnerabilities provide two types of vulnerabilities:

  1. For Go system or "builtin" packages, there is a path and a Go SDK/runtime version and no package name For instance https://pkg.go.dev/vuln/GO-2023-2185

  2. For other packages, there is a package name and separately a file path(s?) and symbols For instance https://pkg.go.dev/vuln/GO-2023-2115

Some other data sources may conflate the package and paths like in Gitlab where we have a package with and without "subpath" for the same vulneraility:

Solution

For VulnerableCode, let's use the Go way for Go and we will not use path in a PURL namespace/name and not in a subpath.

Since at scan time, ScanCode and other tool may have a PURL with full paths instead, we will need to be smart about this in our API and UI code and have some special processing for Go.

In the future, we may need to evolve refinements of the PURL spec to always include paths in the name or never include it like today with subpath.

pombredanne commented 7 months ago

Note that in the future we will need to store paths and symbols to support reachability #1313

TG1999 commented 7 months ago

For example: