-
Notifications
You must be signed in to change notification settings - Fork 574
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
question: Why are CVEs being ignored? #2242
Comments
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
You'll find a section with the 819 vulnerability matches, which are subsequently ignored, like this:
(trimmed for brevity) Note how these are all in the upstream 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
e.g. (note the number of ignored is 0)
vs the default: (note the number of ignored matches your initial report)
I hope that explains how it works. If not, feel free to provide more details. 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 |
@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:
The text was updated successfully, but these errors were encountered: