There is one discussion. Technically, toolchain is not always used for compilation. If the local Go version is newer than the toolchain version, Go uses the local version.

$ go mod init example.com/test
$ go get [email protected]
$ go get [email protected]
$ cat go.mod
module example.com/test

go 1.22.0

toolchain go1.22.2

$ cat main.go
package main

import "fmt"

func main(){
        fmt.Println("hello world")
}
$ go version
go version go1.22.3 darwin/arm64
$ go build ./main.go
$ go version -m ./main | head -n 1
./main: go1.22.3 // <= toolchain go1.22.2 is not used

However, if the local version is older, the toolchain version is used for forward compatibility.

$ go get [email protected]
go: upgraded toolchain go1.22.2 => go1.22.4
$ cat go.mod
module example.com/test

go 1.22.0

toolchain go1.22.4

$ go build ./main.go
go version -m ./main | head -n 1
./main: go1.22.4

They can be configured through GOTOOLCHAIN, but I think it's too much. We can focus on the default behavior.

, auto, or path. GOTOOLCHAIN=auto is shorthand for=local auto

@DmitriyLewen Do you think we should work in the same way?

There is one discussion. Technically, toolchain is not always used for compilation. If the local Go version is newer than the toolchain version, Go uses the local version.

Hmm... I didn't look at that.
In this case, I don't know how we can correctly determine stdlib version. We need to define the local version of Go, but GOROOT is not a required env.

This seems to be the same case as for the SDK in Dark.
We can only show a minimal version.

Do you think we should work in the same way?

Let's start from default logic.
We will handle GOTOOLCHAIN ​​later if users need it.

This is how govulncheck works.
https://github.com/golang/vuln/blob/d9ad5223849a23e412d4a6ac1f61ecfc94cab0d8/internal/scan/run.go#L89-L93

go version actually respects go.mod.

$ go get [email protected]
go go: downgraded toolchain go1.22.4 => go1.22.3
$ cat go.mod
module example.com/test

go 1.22.0

toolchain go1.22.3

$ go version
go version go1.22.3 darwin/arm64

$ go get [email protected]
go: upgraded toolchain go1.22.3 => go1.22.4
$ cat go.mod
module example.com/test

go 1.22.0

toolchain go1.22.4
$ go version
go version go1.22.4 darwin/arm64

But I'm still not sure this is a good approach. If the environment in which Trivy is run is different from the environment in which the project is built, the vulnerability may be overlooked. Also, people can be confused as a vulnerability may be detected or not detected even though they scan the same project.

https://github.com/golang/vuln/blob/d9ad5223849a23e412d4a6ac1f61ecfc94cab0d8/internal/scan/run.go#L89-L93

I thought that we don't want to run other apps in Trivy, even if it's go.

But I'm still not sure this is a good approach. If the environment in which Trivy is run is different from the environment in which the project is built, the vulnerability may be overlooked. Also, people can be confused as a vulnerability may be detected or not detected even though they scan the same project.

in this case, users will need to check (or just be mindful) of many things when scanning go.mod file.
e.g. version of my local Go is not equal to version of Go from our CI/CD.
When i will scan go.mod => i can get a vulnerable binary (or I will need to scan binary again, but then why would I scan the go.mod)

OK, it is better to use the toolchain version at the moment for reproducibility. Since it's technically different from how the Go version is selected for compiling a binary, we should document it.

Yeah. I will update docs.

@knqyf263 i updated docs.
Please take a look.
You might want to add something.