Content of go.sum and modules really used by a go application

I'm trying to compare the behavior of go mod tidy (and the resulting content of go.sum) to the output of go list -m all.
Reading the docs, I understand go.sum contains the whole list of dependent modules declared in go.mod and in dependencies' go.mod files, go list -m all shows the modules really loaded during the execution.
As an example, an application including logrus and prometheus like this:

go.mod

module mytest

go 1.14

require (
        github.com/prometheus/common v0.4.0
        github.com/sirupsen/logrus v1.8.1
)

main.go

package main

import "github.com/sirupsen/logrus"
import "github.com/prometheus/common/version"

func main() {
  logrus.Info("Hello World")
  logrus.Infof("Prometheus info: %v", version.Info())
}

After go mod tidy, go.sum shows both logrus v1.8.1, requested by the go.mod, and 1.2.0, dependency of prometheus v0.4.0; go list -m all shows only v1.8.1.

go.sum

[...]
github.com/sirupsen/logrus v1.2.0/go.mod h1:LxeOpSwHxABJmUn/MG1IvRgCAasNZTLOkJPxbbu5VWo=
github.com/sirupsen/logrus v1.8.1 h1:dJKuHgqk1NNQlqoA6BTlM1Wf9DOH3NBjQyu0h9+AZZE=
github.com/sirupsen/logrus v1.8.1/go.mod h1:yWOB1SBYBC5VeMP7gHvWumXLIWorT60ONWic61uBYv0=
[...]

output of go list

[...]
github.com/sirupsen/logrus v1.8.1
[...]

Is it correct to say the modules really used by the application are listed by go list -m all?

The underlying problem is that a static code analysis detects insecure module versions listed in go.sum, but actually these versions don't show up in go list -m all, hence they shouldn't be really used by the application, but only downloaded during build phase to select the proper minimal version.

Some reference:

https://go.dev/ref/mod#go-mod-tidy

> go mod tidy acts as if all build tags are enabled, so it will consider
> platform-specific source files and files that require custom build
> tags, even if those source files wouldn’t normally be built.

https://go.dev/ref/mod#go-sum-files

> The go.sum file may contain hashes for multiple versions of a module.
> The go command may need to load go.mod files from multiple versions of
> a dependency in order to perform minimal version selection. go.sum may
> also contain hashes for module versions that aren’t needed anymore
> (for example, after an upgrade).

https://github.com/golang/go/wiki/Modules#is-gosum-a-lock-file-why-does-gosum-include-information-for-module-versions-i-am-no-longer-using

> [...]In addition, your module's go.sum records checksums for all
> direct and indirect dependencies used in a build (and hence your
> go.sum will frequently have more modules listed than your go.mod).

https://github.com/golang/go/wiki/Modules#version-selection

> The minimal version selection algorithm is used to select the versions
> of all modules used in a build. For each module in a build, the
> version selected by minimal version selection is always the
> semantically highest of the versions explicitly listed by a require
> directive in the main module or one of its dependencies.
>
> As an example, if your module depends on module A which has a
> require D v1.0.0, and your module also depends on module B which
> has a require D v1.1.1, then minimal version selection would choose
> v1.1.1 of D to include in the build (given it is the highest listed
> require version). [...] To see a list of the selected module versions
> (including indirect dependencies), use go list -m all.

Yes, it correct to say the modules really "used" by the application are listed by go list -m all (as per documentation you provided the link of). By "used", it means the package selected at build time for the compilation of the go code of your application.

We had a similar issue with a static analysis tool and we had to change the configuration to use the output of go list -m all (dumped in a file) instead of go.sum.