Unreported vulnerabilities due to mismatch between package_slugs and go.sum entries

Summary

In this MR, @ifrenkel surfaced a problem when matching the package_slug field of Go advisories with the dependency entries as they appear in go.sum.

For defining the package_slug field for Go advisories, we use the following rule:

In the case of go, for most of the publicly available packages, the package name is the same as it would be used by go get command, e.g., go get gitlab.com/gitlab-org/gitlab-shell with the package name gitlab-org/gitlab-shell. However, we try to be as specific as possible by referring to the vulnerable sub-package in the package name even if it may not be publicly accessible.

The main reason for using the "be as specific as possible" rule is that we want to be able to pinpoint the vulnerable sub-system. If the package slug is as specific as possible, we still can determine the project to which the sub-package belongs through the package_slug. If this information is not provided, we do not exactly know the vulnerable sub-component and, this information would be hard to acquire at a later point in time. Moreover, this information could be valuable for other features we may want to add to dependency scanning in the future.

However, the package_slug may point to an internal package that is not publicly accessible or the URL, through which the dependency is fetched, may be different from the corresponding go.mod entry. Hence, the package_slug cannot be matched 1:1 with the content of the go.sum file. Taking this advisory as an example: the advisory has the package_slug: go/github.com/cactus/go-camo/pkg/camo because the vulnerability was contained in go/github.com/cactus/go-camo/pkg/camo (file pkg/camo/proxy.go file). However, in the go.sum file github.com/cactus/go-camo will appear as dependency instead of github.com/cactus/go-camo/pkg/camo.

Steps to reproduce

  1. Start a new go project
  2. Setup go-camo 1.1.4 as dependency
>> go get github.com/cactus/go-camo/pkg/camo@v1.1.4
go: downloading github.com/cactus/go-camo v1.1.4
go: found github.com/cactus/go-camo/pkg/camo in github.com/cactus/go-camo v1.1.4
>> cat go.sum | grep camo
github.com/cactus/go-camo v1.1.4 h1:zRaM/j+0I8OfJw19JI9MZa+LYWyefKKJoISeE4+7z2I=
  1. No vulnerability reported by gemansium (based on this advisory)

What is the current bug behavior?

No vulnerabilities reported.

What is the expected correct behavior?

A vulnerability should be reported (based on this advisory).

Possible fixes

Making sure that the package slug can be matched with the dependencies mentioned in the lockfile (without preprocessing required on the end of the analyzer) can prevent the problem illustrated above.

Risks

At the moment we are using specific package slugs we may be able to leverage at a later point in time. This information will get lost when using only resolvable packages in the package_slug. Therefore we have to carry this information through by means of a hidden field.

Knowing the URL of the parent git repository URL for a given go sub-module would solve the problem mentioned above.

We discussed two potential solutions to acquire the parent git repository URL in this MR: (1) Derivation from package_slug or (2) the addition of a new data-field to the advisory that contains the link to the git repository where the sources of the package/module are hosted. Derivation from the package_slug can be difficult because the package_slug may be convoluted which makes it difficult to automatically compute the parent git repository. The second option would be to add a new field to the advisory schema (e.g., package_source_url) that points to the parent git repository URL for a given go (sub-)module. This option seems to be preferable because all advisories undergo a review before getting merged where the correctness of the source url can be verified. Moreover, this field would be nice-to-have for all advisories to keep track of the places where the source code of the impacted packages is actually stored. We could potentially build new features that leverage the package_source_url information.

Edited by Julian Thome