Failed to parse constraint of CVE-2024-6345 which fails the scan

[tomersein]

What happened:
I have an image based on alpine 3.20 and the scan fails. The error is:
unable to find matches in DB: provider failed to inflate vulnerability record (namespace="alpine:distro:alpine:3.20" id="CVE-2024-6345" distro="alpine 3.20.2"): failed to parse constraint='< 70.3.0-rc0' format='Apk': unable to parse apk constraint phrase: failed to create comparator for '&{< 70.3.0-rc0}': unable to parse constraint version (70.3.0-rc0): invalid version
What you expected to happen:
Scan should pass
How to reproduce it (as minimally and precisely as possible):
Here is a Dockerfile to reproduce:

# Use the Alpine 3.20 image as the base image
FROM alpine:3.20

# Install the py3-setuptools package
RUN apk add --no-cache py3-setuptools

# Set a default command, you can replace this with the command you want the container to run
CMD ["sh"]

Anything else we need to know?:
I checked on alpine 3.19 and it works.
might it be related to the phrase "rc" inside the constraint?
Environment:

• Output of grype version: 0.79.5
• OS (e.g: cat /etc/os-release or similar): mac

[josh-alles]

I'm having the same issue with Alpine 3.20.2 The same scan worked last week.

One thing that sticks out to me was previously the Vulnerability field was not showing the GHSA instead of the CVE:

NAME INSTALLED FIXED-IN TYPE VULNERABILITY SEVERITY
setuptools 69.5.1 70.0.0 python GHSA-cx63-2mw6-8hw5 High

And now it looks like the error is complaining about the CVE tied to the same vulnerability as the GHSA. Not sure if that's related, but it was the first time I a vulnerability show up as the GHSA.

[wagoodman]

There are multiple things happening here, one being upstream data changing... but aside from that this kind of error should not be fatal (the user should be able to get a grype report even if the data is problematic/unexpected upstream).

Today the vulnerability provider code can raise up errors when the constraint isn't parsed correctly

grype/grype/db/vulnerability_provider.go

Lines 88 to 91 in 4ec46b5

	vulnObj, err := vulnerability.NewVulnerability(vuln)
	if err != nil {
	return nil, fmt.Errorf("provider failed to inflate vulnerability record (namespace=%q id=%q distro=%q): %w", vuln.Namespace, vuln.ID, d, err)
	}

. This should change, specifically any GetBy* methods should not return errors for these cases (unable to inflate vulnerability record from DB), instead we should be logging warnings. Though the user cannot take action to fix this, the state of the vuln data does affect the vuln report (potentially missing results) so we should let the user know without requiring debug.

[spiffcs]

Here is a link to the secfix that's causing the headache - it looks like this was merged a day ago which is an incorrect version constraint for alpine

https://gitlab.alpinelinux.org/alpine/aports/-/blob/3.20-stable/main/py3-setuptools/APKBUILD?ref_type=heads#L39-41

I'll try and get a PR submitted to fix this in the data, but I agree with @wagoodman's statement above as well that we should protect more against this.

Change request filed:
https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/70435

[tomersein]

hi, thanks for the fast investigation!
when do you think this fix will be merged?

[wagoodman]

We'll put in a new release with the error handing in probably today (may even cut a release today), but it isn't clear when the upstream data will be addressed (thus this particular CVE will be omitted from grype results when this error processing fix lands).

[tomersein]

sounds perfect 👍