I want to ask about upstream matches in Grype. Currently Grype results seem to
include all vulnerabilities affecting the upstream package. For example,
python-perf package with upstream of kernel includes all vulnerabilities
affecting the kernel, and php8.3-xml includes all vulnerabilities of php8.3:
grype 'pkg:rpm/centos/python-perf@3.10.0-1160.119.1.el7?arch=x86_64&distro=centos-7&upstream=kernel-3.10.0-1160.119.1.el7.src.rpm'
# ✔ Scanned for vulnerabilities [3639 vulnerability matches]
# ├── by severity: 0 critical, 14 high, 2318 medium, 1294 low, 13 negligible
# └── by status: 0 fixed, 3639 not-fixed, 0 ignored
grype 'pkg:deb/ubuntu/php8.3-xml@8.3.0-ubuntu0.24.04.5?distro=ubuntu-24.04&upstream=php8.3' -o json | grype explain --id CVE-2025-1219
# Match explanation(s):
# - ubuntu:distro:ubuntu:24.04:CVE-2025-1219 Indirect match; this CVE is reported against php8.3 (version 8.3.0-ubuntu0.24.04.5), the origin of this deb package.
Certainly python-perf doesn’t include all vulnerabilities from the kernel, and
php8.3-xml doesn’t include all vulnerabilities from php8.3.
Specifying upstream packages is necessary – Grype just needs it to work
correctly. But sometimes it produces many false positives and a ton of
vulnerable packages affected by the same CVE (every php8.3-anything would
share all vulnerabilities with the upstream php8.3 package).
So the question is, to you as devs and to the broader community, how do you deal
with that situation? We cannot turn upstream matching off, but keeping it on
produces FPs, maintaining a list of exceptions would be a Herculean task.
I certainly have to agree with your assessment that python-perf upstream of kernel is probably not going to result in an accurate set of vulnerabilities and similar for php8.3-xml. The challenge is that we do need to use upstream in some cases: openssl, for example, I believe is upstream of many libs which embed it and results in valid vulnerabilities.
I think we’re definitely open to improving this, I’m just not clear how yet. Without digging in too much, I could think of a couple possibilities that we could investigate:
having some sort of data set in GrypeDB that flags certain upstreams as too broad?
inspecting the type of the upstream if it’s a library like openssl, include it, but not if it’s distributed separately? I’m not entirely sure how to determine this…
Any change here will require some research to determine the impact to matching. Suggestions here are welcome, keeping in mind that many of the upstreams are important to use!
This seems like a good thing to bring up with the team during our livestream – I’ll try to remember to add it next week
I disagree that matching by upstream is useless most of the time. If my understanding is correct, CVEs are published against upstream packages, but Linux distributions often rename or split upstream packages. So to correctly map CVEs to packages, Grype needs the upstream information.
So without upstream matches we would get only vulnerabilities from security trackers of distributions and their quality varies.
high percentage of the CVEs are coming from kernel or linux kernel which is not accurate. Basing the vulnerabilities on NVD results causing lots of noise and FP, which makes it difficult to focus on the relevant CVEs (from my experience)
By the way, it is possible to filter out all indirect matches (matches based on upstream) with a Grype config option. It isn’t documented very well (see the GitHub issue) but it is there for you.
Indirect matches are a unfortunately necessary: many vulnerabilities are reported against the source/upstream packages such as openssl and we have no other information about the specific downstream packages so this is the only thing that Grype is able to use to report critical issues. I think we all want to figure out a way to improve this. I would love to add something in the database that indicates whether a particular package is a source package or not and drive matching only when directed by the data, but I think if it was as easy as adding a flag we would have done this already; I don’t think many (any?) of the data sources have any indication that we could use for this, but I would love to be proven wrong. We are definitely open to discussions about it
I did a little investigation to understand the problem a bit more. In the context of Ubuntu 24.04 and the recent CVE-2026-44235 affecting the librabbitmq4 package:
Vunnel makes use of ubuntu-cve-tracker as the source for the Ubuntu bug tracker
ubuntu-cve-tracker data for CVE-2026-44235 only includes basic information about the vulnerability and lists patches referencing the upstream package
as a result Grype relies on an indirect match based on the upstream package
however, Ubuntu also releases vulnerability information in the OSV format which is richer and references specific packages by name and version that include the fix
so if Vunnel made use of the OSV data, it would reduce reliance on matches based on the upstream package and it could use the downstream package directly.
ubuntu-security-tracker for CVE-2026-44235 (source)
PublicDateAtUSN: 2026-06-11
Candidate: CVE-2026-44235
Patches_librabbitmq:
upstream: https://github.com/alanxz/rabbitmq-c/commit/1d3afbb056fee5cc9ea05680bf32288715d0d802
upstream_librabbitmq: released (0.16.0-1)
noble_librabbitmq: released (0.11.0-1ubuntu0.1)
Grype explain output
grype 'pkg:deb/librabbitmq4@0.11.0-1build2?arch=amd64&distro=ubuntu-24.04&upstream=librabbitmq@0.11.0-1build2' -o json | grype explain --id CVE-2026-44235
✔ Scanned for vulnerabilities [0 vulnerability matches]
├── by severity: 0 critical, 0 high, 2 medium, 1 low, 0 negligible
└── by status: 3 fixed, 0 not-fixed, 0 ignored
CVE-2026-44235 from nvd:cpe (Unknown)
Related vulnerabilities:
- ubuntu:distro:ubuntu:24.04 CVE-2026-44235 (Medium)
Matched packages:
- Package: librabbitmq4, version: 0.11.0-1build2
PURL: pkg:deb/librabbitmq4@0.11.0-1build2?arch=amd64&distro=ubuntu-24.04&upstream=librabbitmq@0.11.0-1build2
Match explanation(s):
- ubuntu:distro:ubuntu:24.04:CVE-2026-44235 Indirect match; this CVE is reported against librabbitmq (version 0.11.0-1build2), the origin of this deb package.
Locations:
URLs:
- nvd
- https://ubuntu.com/security/CVE-2026-44235
I think in the case of Ubuntu there is a data source available that references specific downstream packages affected by a vulnerability. This would reduce reliance on indirect matches by upstream package and increase confidence in the match.
Circling back to the original example in the first comment of this thread, the php8.3-xml package affected by the php8.3 upstream vulnerability, the OSV data doesn’t actually help as it also lists php8.3-xml as affected. So it doesn’t help to narrow down the broad detections.
I’m not convinced it’s worth changing vunnel to consume the OSV source instead.
Just to make sure I’m understanding your conclusions, it sounds like you’re saying that for the librabbitmq CVE, using the OSV helps, but for the php8.3-xml CVE, it doesn’t help. Is that right?
I’m not convinced it’s worth changing vunnel to consume the OSV source instead.
We’ll probably end up converting it at some point for operational simplicity’s sake. The ubuntu-cve-tracker repo sometimes makes changes that take a very long time to parse, we have to maintain a bunch of complex code, etc.
It would also be good to narrow down to the explicit binaries in order to be able to pick up future improvements to the data.
It’s often the case that distro vulnerability data is tied to build system data, so if for example they had to pull in a new upstream source of the php package because of a CVE and rebuild a bunch of things, they’ll mark everything thus rebuilt as if they fixed the CVE in it. Otherwise their researchers have to understand which vulnerable code from the upstream or the origin deb made it into each binary deb, and that is a pretty hard problem.
It wouldn’t make a difference in either case actually as I believe that in both cases all downstream packages are marked as vulnerable by Ubuntu. On the other hand, the package librabbitmq-dev isn’t listed in the OSV data as an affected package, but update to 0.11.0-1ubuntu0.1 is marked as a security update by apt. It’s all a bit confusing.
grype 'pkg:deb/ubuntu/librabbitmq-dev@0.11.0-1build2?arch=amd64&distro=ubuntu-24.04&upstream=librabbitmq'
# ✔ Scanned for vulnerabilities [0 vulnerability matches]
# ├── by severity: 0 critical, 0 high, 2 medium, 1 low, 0 negligible
# └── by status: 3 fixed, 0 not-fixed, 0 ignored
# NAME INSTALLED FIXED IN TYPE VULNERABILITY SEVERITY EPSS RISK
# librabbitmq-dev 0.11.0-1build2 0.11.0-1ubuntu0.1 deb CVE-2023-35789 Low 0.2% (11th) < 0.1
# librabbitmq-dev 0.11.0-1build2 0.11.0-1ubuntu0.1 deb CVE-2026-44235 Medium N/A N/A
# librabbitmq-dev 0.11.0-1build2 0.11.0-1ubuntu0.1 deb CVE-2026-44236 Medium N/A N/A
apt search librabbitmq-dev
# Sorting... Done
# Full Text Search... Done
# librabbitmq-dev/noble-updates,noble-security,now 0.11.0-1ubuntu0.1 amd64 [installed]
# AMQP client library written in C - Dev Files
I think this upstream matching is definitely the source of a lot of confusion and false positives and it would be great to get rid of it, but we would need every downstream package enumerated in the db (which we don’t have in many feeds at the moment; and it could make the db larger by some unknown quantity). Even when we find this often it includes packages that shouldn’t actually be affected: it’s basically the same problem moved somewhere else, or the opposite: it excludes packages that should actually be in the list.
To me, it usually goes back to the same problem: the vulnerability source data is imperfect and we need to be able to curate every bit of data we use with an open process that allows community contribution. I just can’t see another way given the state of what we see today across many of the sources we use.
