Kernel headers ignore

Grype
1

hello!
i’m trying to understand better the kernel-header ignore in grype.
i have this example of image:
I want to understand how can i see if a CVE was ignored, i see the ignore configuration at the end of the schema, but not sure if it is in use or not, or what should i expect if a CVE was ignored.

FROM amazonlinux:2023.5.20240624.0@sha256:5bf791027b4659e73c33a88a3fa2b314b8e2c0ee60cb1088a097171ee7f180db

# Update repositories and install necessary packages
RUN yum update -y && \
    yum install -y tar gzip && \
    yum search kernel | grep 'kernel-' && \
    yum install -y kernel

# Optionally, you can list installed packages to confirm
RUN rpm -qa | grep kernel

example of the schema:

      "ignore": [
        {
          "vulnerability": "",
          "reason": "",
          "namespace": "",
          "fix-state": "",
          "package": {
            "name": "kernel-headers",
            "version": "",
            "language": "",
            "type": "rpm",
            "location": "",
            "upstream-name": "kernel"
          },
          "vex-status": "",
          "vex-justification": "",
          "match-type": "exact-indirect-match"
        },
        {
          "vulnerability": "",
          "reason": "",
          "namespace": "",
          "fix-state": "",
          "package": {
            "name": "linux-headers-.*",
            "version": "",
            "language": "",
            "type": "deb",
            "location": "",
            "upstream-name": "linux"
          },
          "vex-status": "",
          "vex-justification": "",
          "match-type": "exact-indirect-match"
        },
        {
          "vulnerability": "",
          "reason": "",
          "namespace": "",
          "fix-state": "",
          "package": {
            "name": "linux-libc-dev",
            "version": "",
            "language": "",
            "type": "deb",
            "location": "",
            "upstream-name": "linux"
          },
          "vex-status": "",
          "vex-justification": "",
          "match-type": "exact-indirect-match"
        }
      ],
2

Hi @TimBrown1611! Thanks for the question.

If you pass -o json to Grype, any CVEs that were ignored will be reported under the ignoredMatches in the JSON. So if you want to know whether any CVEs were ignored, just look at the JSON output and see if there’s anything under ignoredMatches.

The JSON you pasted is the end of a Grype JSON output, where we are showing the config with which Grype was invoked. Specifically, we are showing the ignore rules.

Grype has a config option called match-upstream-kernel-headers that defaults to false. When this value is false, Grype adds 3 ignore rules to the config:

These 3 rules cause Grype to ignore CVEs that meet the following criteria:

  1. The package name is kernel-headers, linxus-headers-.* (regex match), or linux-libc-dev
  2. The match type is Indirect
  3. The upstream package is called kernel or linux

What this means in simple terms is: When scanning an image, if you find an RPM (or dpkg or apk or whatever) who’s name is kernel-headers and whose upstream is kernel, ignore indirect vulnerabilities. That is, don’t assume that just because an RPM that includes header files related to the kernel is in a container, that a vulnerability in the kernel itself is present in the container.

When scanning images, this makes sense, because there is no kernel in the image, so a kernel vulnerability would be a property of the host running the kernel anyway. Basically, Grype by default won’t report vulnerabilities in the Linux kernel itself against your image just because it has some RPMs with kernel header files in them installed.

Does that make sense? Have I answered your question?

3

hi! yes, the answer was comprehensive.
can I add rules of myself?
recently i am trying to reduce “noise” and duplicate vulnerabilities in VMs scan, most of them from rpm :slight_smile:

4

Yes, you can add ignore rules yourself, see GitHub - anchore/grype: A vulnerability scanner for container images and filesystems

5

is it possible to add more complex rules?
the rules today apply to a single match, however in my case i want an ignore will be at a context of other matches.
for example:
if a match applies to a package from a direct match, don’t include other indirect matches for the same package.

6

Today you would have to do that by post processing Grype’s output; there’s no config for that.

The main use case for ignore rules is basically to say, “we have researched this CVE, and the way we are using this package means that we are not vulnerable, so suppress this CVE for this package,” or similar rules.

7

thanks!
do you think it makes any sense to look into CVEs from indierct \ cpe match, in case other CVEs were provided from direct match?