False positive with pkg:rpm PURLs

[edhinard]

What happened
I used to have my SBOM done with rpm -q. I then change the result in a list of PURLs to feed grype with. The output of grype is sometimes strange:

$ cat dbus.purl 
pkg:rpm/dbus@1.12.8-18.el8?arch=x86_64&epoch=1

$ /opt/grype purl:dbus.purl --distro rhel:8.6
 ✔ Scanned image           [6 vulnerabilities]
NAME  INSTALLED      FIXED-IN           TYPE  VULNERABILITY   SEVERITY 
dbus  1.12.8-18.el8  1:1.12.8-10.el8_2  rpm   CVE-2020-12049  High      
dbus  1.12.8-18.el8  (won't fix)        rpm   CVE-2020-35512  Low       
dbus  1.12.8-18.el8                     rpm   CVE-2022-42010  Medium    
dbus  1.12.8-18.el8                     rpm   CVE-2022-42011  Medium    
dbus  1.12.8-18.el8                     rpm   CVE-2022-42012  Medium    
dbus  1.12.8-18.el8  1:1.12.8-9.el8     rpm   CVE-2019-12749  High      

In this example, the CVEs CVE-2019-12749 and CVE-2020-12049 are fixed in an earlier version of the package.

What you expected to happen
I expect to not have CVE-2019-12749 and CVE-2020-12049 in the output

How to reproduce it
The solution for me is to use syft which then gives satisfactory results. syft can also be used to reproduce the problem as it is easy to extract PURLs from a JSON output with the command jq -r '.artifacts[] | select(.name == "dbus") | .purl' syft.json. We can check that when grype process the syft output the result is OK:

$ /opt/grype syft.json --distro rhel:8.6 | grep "dbus "
 ✔ Scanned image           [1386 vulnerabilities]
dbus 1:1.12.8-18.el8                    rpm   CVE-2022-42011    Medium    
dbus 1:1.12.8-18.el8                    rpm   CVE-2022-42010    Medium    
dbus 1:1.12.8-18.el8                    rpm   CVE-2022-42012    Medium    
dbus 1:1.12.8-18.el8 (won't fix)        rpm   CVE-2020-35512    Low  

Anything else we need to know?

$ /opt/grype version
Application:          grype
Version:              0.53.1
Syft Version:         v0.62.1
BuildDate:            2022-11-21T16:54:40Z
GitCommit:            826726d553e68cb862597a8737b83f7ade898c3b
GitDescription:       v0.53.1
Platform:             linux/amd64
GoVersion:            go1.18.7
Compiler:             gc
Supported DB Schema:  5

the syft output I am working on

the SBOM with rpm:

for pkg in `rpm -qa`; do
  rpm -q $pkg --qf "pkg:rpm/rhel/%{NAME}@%{VERSION}-%{RELEASE}?arch=%{ARCH}%|EPOCH?{&epoch=%{EPOCH}}|"
  echo
done > /tmp/purl.txt

[spiffcs]

pkg:rpm/dbus@1.12.8-18.el8?arch=x86_64&epoch=1&upstream=dbus-1.12.8-18.el8.src.rpm
pkg:rpm/dbus@1.12.8-18.el8?arch=x86_64&epoch=1

@edhinard above is an example of the difference in the PURL outputs

We tried to reproduce this issue and found that both of those PURL were equally incorrect. They both showed the 2 vulnerabilities that were fixed in an earlier package.

When using pkg:rpm/dbus@1:1.12.8-18.el8?arch=x86_64&epoch=1 we were able to see the correct output.
Note the 1:1<--

We'll take a look at the version parsing for the RPM cataloger to make this sure this is not stripped out in a future release of syft.

[spiffcs]

I also moved this to syft since it's a purl generation on the SBOM not grype failing to match.

[kzantow]

I got a little more context about this problem since we discussed this yesterday: think this might actually be a Grype problem or both a Syft/Grype problem. The prefix of 1: in the version string is an epoch value. We are generating PURLs that contain the epoch=1 parameter (and the example PURLs in this issue correctly include it, too), but this doesn't seem to be used appropriately when Grype is doing the scan. The difference is that the SBOM version does include the 1: in the version string, and has RPM Metadata with this epoch value, whereas the PURL does not have either of these things. So we probably need to do some combination of these solutions:

• include the version epoch prefix in the PURLs from Syft (and other tools will need to do this as well) this is against the PURL spec
• decode the purl version that includes an epoch=# to include this prefix
• adjust the grype matching to use rpm metadata epoch instead (maybe it's already doing this... but we would need to somehow decode PURLs to include this metadata)

In the short term @edhinard you can generate PURLs with an <epoch>: prefix, which should work properly for you.

[kzantow]

Given more discussion, I think this does end up being a Grype issue in the purl_provider that needs to properly handle the epoch, so moving this issue back to Grype.