Istio version tagging format causing false positives within vulnerability scanners

twixthehero commented 4 months ago

Is this the right place to submit this?

[X] This is not a security vulnerability or a crashing bug
[X] 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:

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:

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.

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].

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.

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 https://github.com/advisories/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.

howardjohn commented 2 months ago

I don't think we will fix this. istio/istio not intended to be used as a supported library (istio/api and istio/client-go are), much like kubernetes/kubernetes is. You may do so (and you are far from the first), but at your own risk -- there may be massive breaking changes, rough edges, CVE false positives, "incorrect" tagging, etc.

istio.io/istio needs to fix their version tags so that they are recognized by the Go toolchain properly

We will not do this as we are intentionally not Go-versioned and are permanently pre-release

they need to report vulnerabilities to the Github Advisory DB using the pre-release versioning scheme

We will also not do this, as our vulnerabilities are in the Istio product (which spans beyond this repo, too), not the istio.io/istio go package

howardjohn commented 2 months ago

What we could maybe do is not report them as "Go" CVEs though. Not sure if we retroactively do so

istio / istio