[gke-operator][epic] VEX related improvements for the build process

[macedogm]

The VEX Hub initiative in rancher/vexhub is now a mature project in Rancher where we generate VEX reports for known false-positive CVEs in our projects (images and binaries).

In order for VEX to fully work and for security scanners (e.g., Trivy) to correctly match a VEX entry in our VEX Hub with a Go binary being scanned, the Go binary must have its full package path inside of it. Example:

> go version -m bin/gke-operator | head -n 3
bin/gke-operator: go1.23.4
	path	github.com/rancher/gke-operator
	mod	github.com/rancher/gke-operator	(devel)

When a Go binary is compiled by specifying directly the file as go build main.go as opposed to go build ., the binary won't contain the package path.

> go version -m bin/gke-operator | head -n 2
bin/gke-operator: go1.23.4
	path	command-line-arguments

In the above case, the security scanner won't be able to match the binary with its respective VEX entry.

Further automation that we developed internally also relies on identifying the commit ID from where the binary was built.

Some branches of gke-operator have the needed package path, but lack the commit ID. We'll propose some PRs to help improve the build process and add the needed information for Rancher's VEX Hub project. None of those PRs are expected to affect the code's behavior and features, as they are only metadata information.

[macedogm]

PRs:

• VEX related improvements in the build process #783
• [v2.10] VEX related improvements in the build process #784
• [v2.9] VEX related improvements in the build process #785
• [v2.8] VEX related improvements in the build process #786

CC @mbologna and @kkaempf

[kkaempf]

@macedogm all related PRs have been merged. I assume this epic can be considered done !?

[macedogm]

@kkaempf yes, we can close it. Thanks so much for your support on this 🙇🏻