Dependency scanning uses go.sum parser for Go projects that do not produce binaries
The dependency scanner produces a large number of false positives.
From one project, https://gitlab.com/gitlab-com/gl-infra/gitlab-dedicated/instrumentor, I picked 5 dependency scanner vulnerability reports for analysis, to determine their accuracy. Of the 5 dependencies I picked, all 5 were false positives.
Some notes:
- All false positives are for Go module dependencies.
- Some -- but not all -- of the false positives were picked up in
go.sum
but this is not useful since this is not used for dependency resolution. - In 3 cases, the dependencies were already patched from the purported vulnerability at the time it was introduced into the project. The alert then reported on older versions which we were not using.
In the other two cases, we had already patched the vulnerability dependency some time (ie, months) before the report alerted us to the condition.
Dependency scanning is a very important function in the product, but unless it is able to product accuracy results, it does little more than make a noise, and will likely be ignored.
Further details
- In the past when implementing #321081 (closed),
go list
andpackages.Load
seemed equivalent. - We used
packages.Load
because it was easier to integrate. - In #396918 (closed) (this issue) we noticed limitations specific to
packages.Load
. - As a result, we're now switching to
go list
.
Implementation plan
-
Update the Go builder so that it runs go list -json -deps -test -e ./...
instead of using thepackages.Load
functionality from the golang.org/x/tools/go/packages module. -
Add a test that proves that the go.mod parser is used when there are only tests in a Go project. -
Create a new issue to track how many times the go.sum parser is in use. If this solution fixes the go.sum parser usage altogether, we should aim to remove it in the next major milestone (or earlier if possible).
cc @plafoucriere following our discussion on this.
Edited by Fabien Catteau