Issue when using grype on Raspberry Pi OS

[ghollingworth]

What happened:

When using Grype on Raspberry Pi OS, it uses the Debian package list for the packages to match against. But there are some packages that are rebuilt versions of the upstream Debian packages. For example the Chromium package on a Raspberry Pi is actually 1:149.0.7827.114-1~deb13u1+rpt1

The upstream version would be 149.0.7827.114-1~deb13u1 in other words an epoch of 0. We use the epoch to stop the upstream version from automagically overwriting the Raspberry Pi package version because lots of functionality would then be broken (hardware video decode is an example).

But that means when you run Grype it assumes an epoch of 1 is a newer version that anything with an epoch of zero (which is of course the whole point of an epoch) which means we miss vulnerabilities against the upstream package.

Is there a standard / expected way to make this work? Currently I've got two options:

1. Pre-process the SBOM to remove the incremented epoch on packages that we've added it to
2. Post process the vulnerability list to add a scan specifically for the upstream version of any Raspberry Pi package.
3. Modify Grype or add a database etc to know about the difference between upstream and downstream packages. For example, add a Raspberry Pi database to be imported which matches the whole +rpt1 package version which then copies the upstream vulnerability list and adds on any Raspberry Pi specific vulnerabilities

[willmurphyscode]

There is one relevant config that may help: GRYPE_MATCH_DPKG_MISSING_EPOCH_STRATEGY. The possible values are zero which assumes that a package or vuln with no epoch has epoch 0 and auto which assumes when comparing a dpkg version to a vulnerability version, the packages share the same epoch (concretely it drops the epoch before comparison). See config reference. This defaults to zero but changing to auto might improve this situation.

Anyway, that config might help. It sounds like you're putting epoch in as one higher than upstream in many cases to prevent apt and similar from downloading an incompatible upstream? Are you doing this in all cases, or only some? Does Raspbian have a vulnerability data feed we could use? I think we're just matching debian data because of ID_LIKE having debian in it.

It might be possible if this is a consistent pattern to detect Raspbian (is that the same as "raspberry pi os?") and fix the vulnerability data to have the correct epoch?

Grype should be searching by upstream package / origin deb / source rpm (generically "upstream") for debs, apks, rpms, and maybe a few others. If that search is resulting in false negatives, it could be getting confused as well by the epoch mismatch. Anyway, two suggestions:

1. Try rescanning with that config option
2. Attach an SBOM (ideally syft -o json output) to this issue so we can take a look in more detail.

Thanks for the issue! We're always trying to make matching better, so any time there is a systematic gap like this we try to close it.