Incorrect version comparisons for maven packages

[westonsteimel]

What happened:

Currently grype is just using the fuzzy matcher (which falls back to semver when the version is somewhat semver like) for java packages; however, it should really be using the Maven version spec as the semver logic leads to wrong comparisons in some specific cases.

A specific case where grype currently fails is below:

Cloudbees append a -cb-<patch number> to the version when issuing patches to an existing version and currently grype does not consider these correctly in match comparisons.

An example is 2.414.2-cb-5 should be considered > 2.414.2, but grype currently treats it as a pre-releaase

What you expected to happen:

2.414.2-cb-5 should be treated > 2.414.2

How to reproduce it (as minimally and precisely as possible):

grype docker.io/cloudbees/cloudbees-core-mm:2.414.2.2 | grep GHSA-5j46-5hwq-gwh7
jenkins-core                                2.414.2-cb-5           2.414.2                   java-archive    GHSA-5j46-5hwq-gwh7  High

Anything else we need to know?:

Environment:

• Output of grype version:

Application:         grype
Version:             0.69.0
BuildDate:           2023-09-20T20:56:04Z
GitCommit:           da3de94842f51059f32409289d863792726f83ba
GitDescription:      v0.69.0
Platform:            darwin/arm64
GoVersion:           go1.21.1
Compiler:            gc
Syft Version:        v0.91.0
Supported DB Schema: 5

• OS (e.g: cat /etc/os-release or similar):

[wagoodman]

We don't want this to fall through to fuzzy version comparator, nor do we want the semver comparator since this is against the semver spec (-cb... looks like a pre-release). It looks like we need a new comparator that would take these cases into consideration, or a way to configure the semver comparator we have to treat prereleases as after the versions the reference in a configurable way and select on this when we see -cb....

[westonsteimel]

The existing maven version comparison library that trivy uses: https://github.com/masahiro331/go-mvn-version, already handles this case correctly: https://play.golang.com/p/7b9M5QcUaxu

So maybe we should just be switching to use that?

[westonsteimel]

There are also a good number of test cases at https://github.com/google/osv.dev/blob/master/osv/ecosystems/maven_test.py that we should add in