False positive: GHSA-qhch-g8qr-p497 (CVE-2014-3641) cinder 17.4.1.x, recommend fixed with 2014.x older versioning convention.

[sekveaja]

What happened:
Scan on image that has python3-cinder-17.4.1~dev13-150000.1.142.noarch installed.
It generates vulnerabilities:

$ grype --distro sles:15.5 <custom_image> | grep cinder

NAME INSTALLED FIXED-IN TYPE VULNERABILITY SEVERITY
cinder 17.4.1.dev13 python GHSA-r4v4-w9pv-6fph High
cinder 17.4.1.dev13 2014.1.3 python GHSA-qhch-g8qr-p497 Medium (This one is not right)
cinder 17.4.1.dev13 19.1.2 python GHSA-7h75-hwxx-qpgc Medium

What you expected to happen:

OpenStack changed versioning system between Kilo and Liberty in 2015. Up to Kilo they used the year as a base resulting in 20xx.x.x versions. From Liberty they started to use semantic versioning in every project. 
This resulted lower version numbers for the newer projects that the tools cannot handle now. 
   
  e.g. Cinder became 7.0.0 in Liberty after the  2015.1.4 Kilo version

See reference:     
   https://releases.openstack.org/liberty/index.html
   https://releases.openstack.org/kilo/index.html
   

Vulnerability GHSA-qhch-g8qr-p497 may applied for Openstack package (Kilo) that is released before 2015.
We use version 17.4.x that is aligned with new versioning convention, hence, this is a false positive.

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

There is no public repository that has this package python3-cinder-17.4.1~dev13-150000.1.142.noarch.
However, there is a public tar file that can be downloaded and reproduce the issue.

1. Download the tar file from the pubic repo

wget https://tarballs.opendev.org/openstack/cinder/cinder-17.4.0.tar.gz

2. Scan the the tar file

grype ./cinder-17.4.0.tar.gz

NAME INSTALLED FIXED-IN TYPE VULNERABILITY SEVERITY
cinder 17.4.0 python GHSA-r4v4-w9pv-6fph Medium
cinder 17.4.0 2014.1.3 python GHSA-qhch-g8qr-p497 Medium (problem is reproduced)
cinder 17.4.0 19.1.2 python GHSA-7h75-hwxx-qpgc Medium

Environment:

• Output of grype version:

$ grype version
Application: grype
Version: 0.83.0
BuildDate: 2024-10-31T00:04:47Z
GitCommit: 0602464
GitDescription: v0.83.0
Platform: linux/amd64
GoVersion: go1.23.1
Compiler: gc
Syft Version: v1.15.0
Supported DB Schema: 5

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

]$ cat /etc/os-release
NAME="Red Hat Enterprise Linux"
VERSION="8.7 (Ootpa)"
ID="rhel"
ID_LIKE="fedora"
VERSION_ID="8.7"
PLATFORM_ID="platform:el8"
PRETTY_NAME="Red Hat Enterprise Linux 8.7 (Ootpa)"

[spiffcs]

Thanks @sekveaja - we've not encountered this before and are going to take some time as a team to discuss the way forward. We would happily fix this if we had a clear path, but the change of a version constraint during a projects lifetime probably requires some design or extra thought before we get that kind of logic into grype to fix this FP.

Thanks again for the issue!

[sekveaja]

@spiffcs thank you to take a look at it.
There are more related to Openstack and I will continue to report in the meantime.
Thanks

[wagoodman]

There isn't anything like an epoch (like with RPMs) to use to say "this version is not comparable with this other version". The best idea we came up with in the live stream is to detect when left hand and right hand major version have different semantics, such as "left hand looks like an incrementing number and right hand looks like a year". But it isn't clear what to do about it other than drop the candidate match.

One part of this could be that grype-db emits an epoch-like value for select packages.

[spiffcs]

Linking #2262 here since we discussed this on a past livestream. These issues still need more research on how we want to approach packages that change their versioning semantics in the middle of their lifecycle.

[willmurphyscode]

#2252 is another example if this issue.