Closed samcornwell closed 2 weeks ago
Hi @samcornwell - thanks for the question and steps to reproduce; much appreciated! I think I can explain this behavior.
The reason will be revealed if you run grype
with an extra v
for more verbose output. Jump to the part you're concerned about [0009] INFO ignored 819 vulnerability matches
grype -vv docker:test
You'll find a section with the 819 vulnerability matches, which are subsequently ignored, like this:
[0009] INFO ignoring 819 matches due to user-provided ignore rules
[0009] INFO found 888 vulnerability matches across 233 packages
[0009] DEBUG ├── fixed: 0
[0009] DEBUG ├── ignored: 0 (due to user-provided rule)
[0009] DEBUG ├── dropped: 0 (due to hard-coded correction)
[0009] DEBUG └── matched: 888
[0009] DEBUG ├── unknown severity: 0
[0009] DEBUG ├── negligible: 29
[0009] DEBUG ├── low: 46
[0009] DEBUG ├── medium: 812
[0009] DEBUG ├── high: 1
[0009] DEBUG └── critical: 0
[0009] INFO ignored 819 vulnerability matches
[0009] DEBUG ├── package=pkg:deb/ubuntu/linux-libc-dev@6.8.0-48.48?arch=arm64&distro=ubuntu-24.04&upstream=linux rules=1 vuln=CVE-2012-4542
[0009] DEBUG ├── package=pkg:deb/ubuntu/linux-libc-dev@6.8.0-48.48?arch=arm64&distro=ubuntu-24.04&upstream=linux rules=1 vuln=CVE-2013-7445
[0009] DEBUG ├── package=pkg:deb/ubuntu/linux-libc-dev@6.8.0-48.48?arch=arm64&distro=ubuntu-24.04&upstream=linux rules=1 vuln=CVE-2015-8553
[0009] DEBUG ├── package=pkg:deb/ubuntu/linux-libc-dev@6.8.0-48.48?arch=arm64&distro=ubuntu-24.04&upstream=linux rules=1 vuln=CVE-2016-8660
[0009] DEBUG ├── package=pkg:deb/ubuntu/linux-libc-dev@6.8.0-48.48?arch=arm64&distro=ubuntu-24.04&upstream=linux rules=1 vuln=CVE-2017-0537
[0009] DEBUG ├── package=pkg:deb/ubuntu/linux-libc-dev@6.8.0-48.48?arch=arm64&distro=ubuntu-24.04&upstream=linux rules=1 vuln=CVE-2017-13165
[0009] DEBUG ├── package=pkg:deb/ubuntu/linux-libc-dev@6.8.0-48.48?arch=arm64&distro=ubuntu-24.04&upstream=linux rules=1 vuln=CVE-2017-13693
(trimmed for brevity)
Note how these are all in the upstream linux
(as in, the kernel), but the match is on the linux-libc-dev
package - which contains headers, not the Linux kernel binary code itself.
This was discussed in issue #1762 and implemented in pr #1787 .
You can turn this rule off with this configuration option or environment variable, which defaults to false
meaning "Do not match the kernel header packages with upstream kernel vulnerabilities":
# match kernel-header packages with upstream kernel as kernel vulnerabilities (env: GRYPE_MATCH_UPSTREAM_KERNEL_HEADERS)
match-upstream-kernel-headers: false
e.g. (note the number of ignored is 0)
$ GRYPE_MATCH_UPSTREAM_KERNEL_HEADERS=true grype docker:test
3c27d7d7c7fbc5463
✔ Loaded image sha256:32932619a696e6d05e451c4970699c111e8b78c8bc36f6d3c27d7d7c7fbc5463
✔ Parsed image sha256:32932619a696e6d05e451c4970699c111e8b78c8bc36f6d3c27d7d7c7fbc5463
✔ Cataloged contents 6e47fdba5cf2037b40f1ce0129a7ca687d9aba0f1aaf3d5ba4b1acfc3ca3d52b
├── ✔ Packages [236 packages]
├── ✔ File digests [9,984 files]
├── ✔ File metadata [9,984 locations]
└── ✔ Executables [975 executables]
✔ Scanned for vulnerabilities [888 vulnerability matches]
├── by severity: 0 critical, 1 high, 812 medium, 46 low, 29 negligible
└── by status: 0 fixed, 888 not-fixed, 0 ignored
vs the default:
(note the number of ignored matches your initial report)
$ GRYPE_MATCH_UPSTREAM_KERNEL_HEADERS=false grype docker:test
✔ Loaded image sha256:32932619a696e6d05e451c4970699c111e8b78c8bc36f6d3c27d7d7c7fbc5463
✔ Parsed image sha256:32932619a696e6d05e451c4970699c111e8b78c8bc36f6d3c27d7d7c7fbc5463
✔ Cataloged contents 6e47fdba5cf2037b40f1ce0129a7ca687d9aba0f1aaf3d5ba4b1acfc3ca3d52b
├── ✔ Packages [236 packages]
├── ✔ File digests [9,984 files]
├── ✔ File metadata [9,984 locations]
└── ✔ Executables [975 executables]
✔ Scanned for vulnerabilities [888 vulnerability matches]
├── by severity: 0 critical, 1 high, 812 medium, 46 low, 29 negligible
└── by status: 0 fixed, 888 not-fixed, 819 ignored
I hope that explains how it works. If not, feel free to provide more details. If this covers your question enough, please close the issue at your convenience.
Have a great day! 🙏
Thank you very much for the detailed answer @popey. I think I sort of understand the answer, and I am trying to determine the relevance of these vulnerabilities. Am I right in saying that these vulnerabilities are not relevant in a containerized environment?
No problem @samcornwell - I think the general feeling is that the vast majority (if not all) of those CVEs relate to the Linux kernel itself - the big binary and all those drivers, not the headers, used by third party developers to build software against the kernel. So it's considered noise that you, as a container consumer, probably don't need to see. However, I'm not a security researcher, or lawyer etc, so it's a decision you need to make, I think. :)
Thanks again @popey, I will point out that when testing the config file example you listed, I noticed it should be true
, not false
.
@joshbressers thoughts?
@aaronlippold I'm 100% in favor of this
Kernel headers aren't code, they're headers. One of the difficulties we have when trying to match Linux Distribution data is which built package actually contains the vulnerability in question? The distros don't tell us this, they use the source package name generally.
Here's a better example
When you build emacs, there is a package that gets spit out called "emacs-filesystem". It's just the directory layout for emacs. There's nothing in it
We currently will report it as affected by emacs vulnerabilities today if you have it installed. We don't want to add special conditions for every package like this, so how to solve this better is the question (we're working on it)
The kernel headers were special because all the new kernel vulnerabilities, plus all the kernel headers and you have a silly list of false positives. So we made an exception
I have found that some images are showing the majority of vulnerabilities as
ignored
. Specifically, if run with the-v
flag, it says that they are ignored due to user-provided ignore rules. I have no configuration files and am passing no rules on the command line. Why is this happening?scan:
config:
Dockerfile: