search

microsoft / component-detection

Scans your project to determine what components you use
MIT License
396 stars 81 forks source link

Component Detection Tends to Over-Report Even When the Go Version Is >= 1.17 #1092

Closed yuyue9284 closed 1 month ago

yuyue9284 commented 2 months ago

Hi! Current Golang detector uses go list -m all to get all the dependency which could lead to over report.

Demo repo: https://github.com/yuyue9284/dep-demo/tree/main/root, in this case ,irrelevant holds the code not used by the root module.

The output of the go list -m all under the root folder:

root depa v0.0.0-00010101000000-000000000000 => ../depa depb v0.0.0-00010101000000-000000000000 => ../depb irrelevant v0.0.0-00010101000000-000000000000 => ../irrelevant

To validate the irrelevant does not contribute code to the root module, run the following.

rm -r ../irrelevant/
sed -i '/irrelevant.*/d' go.mod
go mod tidy
go run main.go

The go.mod for Go >= 1.17 should be sufficient to detect the dependencies that have the actual code contributions to the project, so could we just scan the go.mod for this scenario? At least one of the popular open-source solutions Trivy have adopted this method.

In Go 1.17+ projects, Trivy uses go.mod for direct/indirect dependencies. On the other hand, it uses go.mod for direct dependencies and go.sum for indirect dependencies in Go 1.16 or less. Go 1.17+ holds actually needed indirect dependencies in go.mod, and it reduces false detection. go.sum in Go 1.16 or less contains all indirect dependencies that are even not needed for compiling. If you want to have better detection, please consider updating the Go version in your project.

https://github.com/aquasecurity/trivy/blob/29b8faf5faaa02e463cbb54465563b40d5667bf4/docs/docs/coverage/language/golang.md?plain=1#L36C1-L36C98

annaowens commented 1 month ago

Hi @yuyue9284, the logic described here is what our Go Fallback Detector uses. If you'd prefer to use the fallback detector, you can set the environment variable DisableGoCliScan to true.

In Go 1.17+ projects, Trivy uses go.mod for direct/indirect dependencies. On the other hand, it uses go.mod for direct dependencies and go.sum for indirect dependencies in Go 1.16 or less. Go 1.17+ holds actually needed indirect dependencies in go.mod, and it reduces false detection. go.sum in Go 1.16 or less contains all indirect dependencies that are even not needed for compiling. If you want to have better detection, please consider updating the Go version in your project.

Our default detector, Go CLI, has other benefits (like full graph generation), and is considered the source of truth as it's coming from Go itself. Do you have a link to Go CLI's stance on what you've mentioned in this issue?

yuyue9284 commented 1 month ago

Hi @yuyue9284, the logic described here is what our Go Fallback Detector uses. If you'd prefer to use the fallback detector, you can set the environment variable DisableGoCliScan to true.

In Go 1.17+ projects, Trivy uses go.mod for direct/indirect dependencies. On the other hand, it uses go.mod for direct dependencies and go.sum for indirect dependencies in Go 1.16 or less. Go 1.17+ holds actually needed indirect dependencies in go.mod, and it reduces false detection. go.sum in Go 1.16 or less contains all indirect dependencies that are even not needed for compiling. If you want to have better detection, please consider updating the Go version in your project.

Our default detector, Go CLI, has other benefits (like full graph generation), and is considered the source of truth as it's coming from Go itself. Do you have a link to Go CLI's stance on what you've mentioned in this issue?

Hi @annaowens , from the go doc: https://go.dev/ref/mod#graph-pruning

Since a go 1.17 go.mod file includes a require directive for every dependency needed to build any package or test in that module

annaowens commented 1 month ago

Thanks @yuyue9284, I agree on your take regarding not scanning go.sums in v1.17+-- and as I mentioned that's what's currently implemented today (see here).

The docs I'm interested in are those regarding why all dependencies output from go list -m all should not be scanned for vulnerability data. In other words, is there documentation on dependencies from go list output being dev deps or otherwise not used at runtime? Is there an additional flag or indicator in the command output that we could respect to not flag those dependencies if that is the case?

yuyue9284 commented 1 month ago

Thanks @yuyue9284, I agree on your take regarding not scanning go.sums in v1.17+-- and as I mentioned that's what's currently implemented today (see here).

The docs I'm interested in are those regarding why all dependencies output from go list -m all should not be scanned for vulnerability data. In other words, is there documentation on dependencies from go list output being dev deps or otherwise not used at runtime? Is there an additional flag or indicator in the command output that we could respect to not flag those dependencies if that is the case?

Hi @annaowens, the documentation is not very clear on this topic. I created the issue based on my own trial and how Trivy implements the scan logic. I think the only way to understand the logic is to look at the code in: https://github.com/golang/go/tree/master, but I have not digged into it.

annaowens commented 1 month ago

Makes sense, I'm closing this issue as the desired functionality can be gotten from running the fallback detector.

If we're able to find something in the Go CLI documentation about why they've chosen to include this output in the list command, we can reopen this! Otherwise could open an issue on Go CLI itself.