debug/buildinfo: false positives with external scanners flag for go117 binary in testdata

[LaurentGoderre]

Proposal Details

Having the go1.24 source locally includes a test binary that gets correctly identified as a go1.17 binary and thus gets flagged by scanners as having many critical and high vulnerabilities that are false positive.

While I don't deny that scanners could be better at detecting false positive, the current state is that this version being incorrectly flagged as having this many vulnerabilities might turn away some users from using it.

A vex statement is fairly unobtrusive way to help scanners in the scanner not to flag these false positive and is a minuscule hinderance compared to having to justify to an IT department why these issues don't apply.

[prattmic]

Extra context here is that https://go.dev/cl/601457 add a binary built with Go 1.17 into debug/buildinfo/testdata, for use in a test that debug/buildinfo can parse buildinfo from pre-1.18 binaries (1.18 changed the buildinfo format).

Apparently security scanners don't like this. e.g., see the "vulnerabilities" on the 1.24.0 Docker image: https://hub.docker.com/layers/library/golang/1.24.0/images/sha256-4a181d3b032caf592eef9390159f5b54b64dfd043bedb9822a015d788e1352a3

Most of these probably don't apply at all (the binary is literally just func main() {}), so it doesn't seem that this scanner is using govulncheck. But even if it were, I'm not sure it matters since this is just test data.

[prattmic]

cc @golang/runtime @golang/release @golang/security

[prattmic]

The proposed vex file can be seen in https://go.dev/cl/649335.

[seankhliao]

given that govulncheck works properly on the binary, I don't see why it's necessary for the go tree to have this file.

plus, that openvex file is a massive list of currently known vulnerabilities, do we have to update it every time some new vulnerability is discovered to affect previous go versions as well?

I think it's more appropriate to generate a list at the time of scanning, e.g. the docker image should scan and add the report at the time they build and publish the container image

[prattmic]

We could eliminate this binary entirely and build it on demand, but that is a bit unfortunate because that means the test will need an internet connection to download a Go 1.17 toolchain.

[prattmic]

It's ugly, but we could also clear the executable bit on this binary. Would that appease scanners?

[seankhliao]

I don't think so, at least some of them sniff file contents directly for signatures

[cherrymui]

We could base64 encode them, like e.g. debug/macho/testdata/gcc-amd64-darwin-exec.base64

[seankhliao]

How many scanners are going to trust a report just laying there? None of the ones I've had to work with allowed that. (if only it were so easy to hide vulnerabilities...)

[ianlancetaylor]

We aren't going to add a vex statement, so taking this out of the proposal process.