Jfrog Xray finds inherent vulnerabilities in Go binaries compiled with Go 1.12, such as testdata/exe.exe in this repo. (full report.) I found that replacing the executable with a binary compiled with Go 1.21 or above causes Xray to find zero of these vulnerabilities. (There is one medium finding when compiled on 1.20.14.) I'd like to suggest to go ahead and replace the exe.exe file, so that there are as few barriers as possible to consuming this very useful Go package.

This issue has been alluded to in the past, but no action was taken because security tooling in general ought to ignore test data. While I agree, I can also see how managing per-repo test data conventions and exceptions becomes exponentially compounded when inspecting Go package dependencies. So where possible, it would be more convenient overall if the vulnerabilities simply didn't exist in the first place.

From what I can tell, the exe.exe file is only used to check whether a file is a legit binary executable. (It may not even ever be executed directly?) It seems that an arbitrary binary would work here. I compiled a Hello World app in Go 1.22 with the following source code:

package main

func main() {
	println("Hello World!")
	return
}

And I tested this replacement exe.exe file in my fork with success -- both with Jfrog Xray scan of my fork (before and after proving that the vulns go away) as well as validating that all the unit tests in go.yml GitHub Action workflow still pass (as long as the binary was compiled for the Windows platform, interestingly enough).

I do plan to submit a PR here with the binary that I tested once I obtain organizational permission for this OSS contribution.