What about a -platforms <comma-separated-list> flag that could accept all or linux,windows values.

Based on an offline discussion, this should apply for the analysis of source code only. Users will likely apply govulncheck on binaries ready for deployment, so we can use os and system architecture info present in the binary.

What about a -platforms <comma-separated-list> flag that could accept all or linux,windows values.

Interesting idea, but I think we could add a line in the output for each vulnerability that also specifies to which os and archs the vuln applies to. This would avoid the need for the flag and would not complicate the output too much for the user.

  ...
  Found in: ...
  Fixed in: ...
  More info: ...
  GOOS: linux, windows
  GOARCH: all

Something like that.

Change https://go.dev/cl/432356 mentions this issue: vulncheck: Source returns vulns for all GOOS/GOARCH

@zpavlinovic If I run govulncheck on my macOS machine (without any GOOS, GOARCH overrides), after this fix, will it discover callpaths that affect only Windows, automatically? Or will this vulnerability get reported in the "Informational vulnerabilities" section (non-affecting vulnerabilities)?

It will discover vulns that affect only Windows. They will be reported with

platforms: windows/amd64

so you can tell.

Imagine that you develop on Mac but deploy to Linux servers. We don't know that, but we don't want you to miss a vulnerability.

To clarify my question - will it be in the "Affecting vulnerability" section (for those with call info) or in the "Non-affecting vulnerability" section (for those without call info)?

To answer my question - given that govulncheck still depends on go/packages and there is no special massaging to load all sources (this is a known difficult problem), if the call path exists only in a specific platform, that will be reported in the "Informational" section. Users can still adjust GOOS/GOARCH and rerun govulncheck to verify their code is indeed clean.

With this change, govulncheck will create vulnerability graphs as if all of the vulnerabilities apply to all of the platforms. When we present the vulnerability info in the end, then we will simply mention which specific platforms this vulnerability applies to.

I guess in theory it could happen that different underlying platforms can produce different compiled code, but I am not sure will that affect vulnerability detection in practice. I guess this mostly applies to the standard library?

For example https://pkg.go.dev/vuln/GO-2022-0493 is a vulnerability in golang.org/x/sys/unix or syscall for unix. I guess users who run govulnceck on windows wouldn't hit this code path even though their cross-platform projects may be affected if they are built on unix platform.

Hmm, I just realized this vulnerability won't be even reported in the informational section since golang.org/x/sys/unix package won't be imported. Or is the "Informational vulnerability" section based on the module requirement graphs?

For example https://pkg.go.dev/vuln/GO-2022-0493 is a vulnerability in golang.org/x/sys/unix or syscall for unix. I guess users who run govulnceck on windows wouldn't hit this code path even though their cross-platform projects may be affected if they are built on unix platform.

This was the behavior before. This issue is about showing them that path regardless of what platform they are using: we show them that path and then mention that it would be exercised on the windows platform.

We want to do this because users might run govulncheck on one platform during development where the vulnerability does not exist. That could give them a false sense of security if they also don't run govulncheck on other platforms for which some vulnerabilities do apply. Also, it is probably a better user experience doing things this way rather than the user running govulncheck on all possible platforms.

Hmm, I just realized this vulnerability won't be even reported in the informational section since golang.org/x/sys/unix package won't be imported. Or is the "Informational vulnerability" section based on the module requirement graphs?

It should be based on the package imports graph.