Grype returns indirect vulnerability matches on 'kernel' source rpms for the 'kernel-headers' rpm for container images that don't have the kernel

[zhill]

What happened:
Build an image with gcc installed from RedHat/UBI 8, and scan it with Grype and note vulnerabilities found on the 'kernel-headers' package that are matched via indirect lookups on the 'kernel' source RPM.

What you expected to happen:
I don't expect to see CVEs on the kernel-headers package since it does not contain the actual kernel.

How to reproduce it (as minimally and precisely as possible):
Build an image with this Dockerfile:

FROM registry.access.redhat.com/ubi8/ubi
RUN yum -y install --setopt=tsflags=nodocs gcc

Match Details:

 ...
 {
   "vulnerability": {
    "id": "CVE-2022-0886",
    "dataSource": "https://access.redhat.com/security/cve/CVE-2022-0886",
    "namespace": "redhat:distro:redhat:8",
    ...
    
 "matchDetails": [
    {
     "type": "exact-indirect-match",
     "matcher": "rpm-matcher",
     "searchedBy": {
      "distro": {
       "type": "redhat",
       "version": "8.9"
      },
      "namespace": "redhat:distro:redhat:8",
      "package": {
       "name": "kernel",
       "version": "4.18.0-513.18.1.el8_9"
      }
     },
     "found": {
      "versionConstraint": "none (rpm)",
      "vulnerabilityID": "CVE-2022-0886"
     }
    }
   ],
    "artifact": {
    "id": "1468511e21d69381",
    "name": "kernel-headers",
    "version": "4.18.0-513.18.1.el8_9",
    "type": "rpm",
    "locations": [
     {
      "path": "/var/lib/rpm/Packages",
      "layerID": "sha256:d46a662dc8788fc7780786c5d9ff576b615ebcea65b6027e9736aa022f3c84c0"
     }
    ],
    "language": "",
    "licenses": [
     "GPLv2 and Redistributable, no modification permitted"
    ],
    "cpes": [
     "cpe:2.3:a:kernel-headers:kernel-headers:4.18.0-513.18.1.el8_9:*:*:*:*:*:*:*",
     "cpe:2.3:a:kernel-headers:kernel_headers:4.18.0-513.18.1.el8_9:*:*:*:*:*:*:*",
     "cpe:2.3:a:kernel_headers:kernel-headers:4.18.0-513.18.1.el8_9:*:*:*:*:*:*:*",
     "cpe:2.3:a:kernel_headers:kernel_headers:4.18.0-513.18.1.el8_9:*:*:*:*:*:*:*",
     "cpe:2.3:a:kernel:kernel-headers:4.18.0-513.18.1.el8_9:*:*:*:*:*:*:*",
     "cpe:2.3:a:kernel:kernel_headers:4.18.0-513.18.1.el8_9:*:*:*:*:*:*:*",
     "cpe:2.3:a:redhat:kernel-headers:4.18.0-513.18.1.el8_9:*:*:*:*:*:*:*",
     "cpe:2.3:a:redhat:kernel_headers:4.18.0-513.18.1.el8_9:*:*:*:*:*:*:*"
    ],
    "purl": "pkg:rpm/rhel/kernel-headers@4.18.0-513.18.1.el8_9?arch=aarch64&upstream=kernel-4.18.0-513.18.1.el8_9.src.rpm&distro=rhel-8.9",
    "upstreams": [
     {
      "name": "kernel",
      "version": "4.18.0-513.18.1.el8_9"
     }
    ],
    "metadataType": "RpmMetadata",
    "metadata": {
     "epoch": null,
     "modularityLabel": ""
    }
   }
  },

Anything else we need to know?:

Environment:

• Output of grype version:

pplication:         grype
Version:             0.74.7
BuildDate:           2024-02-26T18:24:14Z
GitCommit:           987238519b8d6e302130ab715f20daed6634da68
GitDescription:      v0.74.7
Platform:            darwin/arm64
GoVersion:           go1.21.7
Compiler:            gc
Syft Version:        v0.105.1
Supported DB Schema: 5

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

[wagoodman]

Summarizing some offline conversations... a path forward here could be to:

• For RHEL environments only: drop or filter matches that are against kernel-headers and are an indirect match.
• For Debian environments only: drop or filter matches that are against linux-headers and are an indirect match.

The distinction between dropping and filtering (showing up in the ignored matches section) should be considered carefully.

[zhill]

If possible, I'd prefer to filter to ignored matches rather than opaquely dropping, since the matches are valid based on the data. The issue is the semantics of those specific packages and their known relationships.

[zhill]

I've started working on something here to add a new built-in set of ignore rules that would apply by default but able to be skipped via a config option.

[zhill]

I've looked into the debian-based case and it looks like the kernel headers packages are less stably-named there so I'll focus my efforts initially on RPM/redhat-based solution and then we can discuss things like if we want to support ignore rules that do a package-name wildcard match (e.g. "linux-headers-*" since debian uses "linux-headers-amd64" and "linux-headers-arm64") so the issue manifests a little bit differently in those distros.

[zhill]

note: this still needs an update for the non-rpm cases.