Go mod pseudo-versions may cause false positive results

[FrimIdan]

What happened:
Go program with pseudo versions in go.mod/sum cause false positive results

How to reproduce it (as minimally and precisely as possible):
Create a go program that points to

istio.io/istio v0.0.0-20220308185742-91533d04e894

(go get istio.io/[email protected])

Scan it with grype.

You will get the following results

istio.io/istio                        v0.0.0-20220308185742-91533d04e894                          1.11.7    go-module  GHSA-856q-xv3c-7f2f  High
istio.io/istio                        v0.0.0-20220308185742-91533d04e894                          1.12.18   go-module  GHSA-xwx5-5c9g-x68x  Medium
istio.io/istio                        v0.0.0-20220308185742-91533d04e894                          1.9.8     go-module  GHSA-7774-7vr3-cc8j  High
istio.io/istio                        v0.0.0-20220308185742-91533d04e894                          1.9.8     go-module  GHSA-hqxw-mm44-gc4r  High

which are false positive since v0.0.0-20220308185742-91533d04e894 is istio version 1.13.2

Environment:

• Output of grype version:

$ grype version
Application:          grype
Version:              0.50.1
Syft Version:         v0.56.0
BuildDate:            2022-09-13T18:32:52Z
GitCommit:            403a535321c20565676dc633344e2bf8881cee29
GitDescription:       v0.50.1
Platform:             darwin/amd64
GoVersion:            go1.18.5
Compiler:             gc
Supported DB Schema:  4

[kzantow]

Good find @FrimIdan! I can confirm your example. Digging in to this a bit, let me put the pseudo-versions documentation notes:

Each pseudo-version may be in one of three forms, depending on the base version. These forms ensure that a pseudo-version compares higher than its base version, but lower than the next tagged version.

• vX.0.0-yyyymmddhhmmss-abcdefabcdef is used when there is no known base version. As with all versions, the major version X must match the module’s major version suffix.
• vX.Y.Z-pre.0.yyyymmddhhmmss-abcdefabcdef is used when the base version is a pre-release version like vX.Y.Z-pre.
• vX.Y.(Z+1)-0.yyyymmddhhmmss-abcdefabcdef is used when the base version is a release version like vX.Y.Z. For example, if the base version is v1.2.3, a pseudo-version might be v1.2.4-0.20191109021931-daa7c04131f5.

I think what we are looking at is a bit of a twofold:

• The root of the problem seems to be the way isito is tagging its releases. From what I can tell in the go mod docs, tags should be prefixed with a v, but as you can see in the repo, they are not being tagged this way. The result is that go mod is not finding the correct semantic version, and thus treating these as pseudo-versions. This is not ideal, as many tools will have the same result of v0.0.0. This should be changed
• The other problem is, as you point out here: for these versions, Grype doesn't have a good way of identifying a version number.

It's possible some network requests such as following commit SHAs to the repositories and such could help. This would require handling this one specific case that we have a semver not prefixed with a v, but this doesn't fit with the current philosophy of Syft (which is what is actually surfacing this information to Grype) to be a static analysis tool.

We could potentially exclude pseudo-versions, but then we would be missing valid vulnerabilities, which isn't good, either.

I'll note that we are currently looking at improving package identification in a number of areas that may include getting more information via the network, so this is something that might be able to be accounted for in the future.

However, I would say the right thing to do here is bring this up with the istio team. If they didn't want to change the versioning altogether, I wonder if a possible solution would be to add TWO tags for each of the releases, one of which is prefixed with a v, which could be used properly with go mod.

[FrimIdan]

@kzantow Thanks for the detailed answer.
I know that istio is not using a v prefix and assume that is the problem, I just wonder if istio is the only repo that does it.
I also understand that syft is a static analysis tool but I do think that maybe grype should "fill" that gap when pseudo-versions with v0.0.0 prefix is found.

I've open istio/istio#41702 to check what is the reason not to use v prefix tags in istio.

[kzantow]

Thanks for following up with istio @FrimIdan! We are definitely interested in finding more ways to identify things, as noted earlier. I'll follow up here when we have a more concrete plan that might be able to address issues like this.

[kzantow]

Given the response from Istio about not expecting that repository to be used as a library, it looks like we probably won't be able to surface proper version information for a while. There is a fairly easy workaround to ignore matches in Grype.

In your .grype.yaml, I think this would be something like:

ignore:
  - package:
      name: istio

[willmurphyscode]

Here are some specific repro steps (happening today with istio latest)

Make a package like this:

go mod init example.com/grype972
go get istio.io/istio

Make a main.go like this:

package main

import (
	"fmt"
	_ "istio.io/istio/pkg/fuzz"
)

func main() {
	fmt.Println("Hello world")
}

Then go mod tidy and go build -o ./foo main.go && grype ./foo and the issue is still present.

I think the issue may be because the isio github repo uses version tags that do not start with "v".

[wagoodman]

What we're missing is the ability to know when the tags used to represent the version do not follow semver (in this case with a v prefix) so the version component will always be v0.0.0.

I think in this circumstance we could try to add a golang version comparator that takes the special case of a v0.0.0 vs a non v0.0.0 is probably wrong. The problem is that this is not always true, so maybe this should be a configurable. Or lean towards Keiths suggestion of using the go proxy to detect this case (also opt in via config).

[willmurphyscode]

This needs investigation - we want to compare the different approaches mentioned by @wagoodman at #972 (comment). We can discuss once there are some concrete examples to decide among.