Istio version tagging format causing false positives within vulnerability scanners

[twixthehero]

Is this the right place to submit this?

• This is not a security vulnerability or a crashing bug
• This is not a question about how to use Istio

Bug Description

Problem

Our team uses istio directly as a dependency in Golang. Our go.mod contains the following:

require (
  istio.io/istio v0.0.0-20231127165933-50e191c183e2
)

Vulnerability scanners like TwistLock and the one from GCP Container Registry report the following CVEs:

• https://nvd.nist.gov/vuln/detail/CVE-2022-23635
• https://nvd.nist.gov/vuln/detail/CVE-2021-39155
• https://nvd.nist.gov/vuln/detail/CVE-2019-14993
• https://nvd.nist.gov/vuln/detail/CVE-2022-31045
• https://nvd.nist.gov/vuln/detail/CVE-2021-39156

These scanners seem to be comparing against the version 0.0.0 because this is what is listed in go.mod. In reality, the SHA 50e191c183e2 is associated with version 1.17:

$ git clone https://github.com/istio/istio.git
$ cd istio
$ git log 50e191c183e2
commit 50e191c183e29b61ee1be034760e173e27e5f8fd (origin/release-1.17)
Author: Istio Automation <istio-testing-bot@google.com>
Date:   Mon Nov 27 08:59:33 2023 -0800

    Automator: update proxy@release-1.17 in istio/istio@release-1.17 (#47981)

commit aea0144e18b42decd8670499ebd569da8845275e
Author: Istio Automation <istio-testing-bot@google.com>
Date:   Wed Nov 22 11:53:24 2023 -0800

    Update BASE_VERSION to 1.17-2023-11-22T19-02-41 (#48004)

A member of the GCP Container Registry scanner team did some investigation and explained the following:

1. Go module versions are resolved by using repository tags for each version, so e.g. github.com/gorilla/mux v1.8.0 resolves to the tagged release at https://github.com/gorilla/mux/tree/v1.8.0.
2. If you look at the Go module reference (https://go.dev/ref/mod#versions), you will see that the versioning syntax for Go packages is vX.Y.Z[-optional-suffix].
3. Now, if you look at the source repo for istio.io/istio at https://github.com/istio/istio, you will see that they are tagged in the format X.Y.Z (missing the prefix v).
   • This means that the Go toolchain will not recognize it as an actual version and treats the entire module as if it's in a pre-release state (see https://go.dev/doc/modules/version-numbers#in-development), which is how you get the automatically generated v0.0.0-[timestamp]-[commit hash] versions in your go.mod file.
4. This isn't necessarily an issue in and of itself if the module is truly in a pre-release state, but it seems the issue is that vulnerabilities are being reporting on Github based on the "real" version numbers (e.g. < 1.11.7 in GHSA-856q-xv3c-7f2f) rather than the pre-release version numbers that are being used by the Go toolchain.

They suggested the two following solutions:

• istio.io/istio needs to fix their version tags so that they are recognized by the Go toolchain properly
• OR they need to report vulnerabilities to the Github Advisory DB using the pre-release versioning scheme

Ask

Are either of these two solutions feasible? Is there a reason why the v prefix is not currently being used?

Personally, I think adding the v prefix makes more sense since it would allow proper recognition by the Go toolchain.

Version

All

Additional Information

I found #14770 which includes a doc mentioning the versioning would include vX.Y.Z (notice v prefix) but the tags don't seem to be using this--only the "Main development work on the master branch" section does not use a v prefix.