Should Trivy's vulnerability scanner be enabled by default? #7052
Replies: 2 comments 2 replies
-
|
Moved this to a discussion. Of course it's trivial to disable vulnerability scanning by providing a customized configuration file for Trivy. What are Trivy defaults in this case? |
Beta Was this translation helpful? Give feedback.
-
|
According to the Trivy's doc:
Currently super-linter adds misconfigurations and keeps vulnerabilities and secrets. I feel like misconfigurations and secrets are natural choices for super-linter. My doubt is about vulnerabilities. As Trivy's documentation says:
So we are not talking about vulnerabilities in the project's code or configuration (these get filed under misconfigurations and that's in scope for super-linter). What Trivy calls vulnerabilities are CVEs in dependencies. It feels like a completely different space. As you said it's easy enough to disable the vulnerability scanner if someone wants to. I am just wondering if it's the right direction for super-linter? I also understand that disabling the vulnerability scanner now that it is enabled by default might be tricky (some people may rely on it now) so there's probably no clear cut answer. Cheers, Tom |
Beta Was this translation helpful? Give feedback.
-
|
For now, let's keep vulnerability scanning enabled, so we avoid a breaking change. Thanks for taking the time for letting us know! |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Is there an existing issue for this?
Current Behavior
Hi,
I guess this is more a question/discussion than a feature request at this point but I noticed recently that Trivy's vulnerability scanner is reporting CVEs in my project's dependencies. I am very much in favor of monitoring and patching CVEs in a project dependencies so I see the value in getting these notifications. But I am already using another tool for that. And I am running it on a schedule, not for each commit/PR. That's because I am blocking merging any commit that breaks
super-linter. CVEs can come up at any time and are usually unrelated with the commit being merged so I don't want to block a dev that's trying to deliver something completely unrelated.Now it is possible that the current commit is introducing a new dependency with a CVE so I can imagine some people would prefer to know, and eventually have to manually override the branch protection rule to force the merge of a commit once they checked that the CVE was not introduced by it. But in my experience more often than not the CVE will be unrelated to the commit.
I know that I can reconfigure Trivy to disable the vulnerability scan, I am just wondering what's the right default for
super-lintergiven how most people use it?Cheers,
Tom
Expected Behavior
Do not fail on vulnerabilities by default?
Anything else?
No response
Beta Was this translation helpful? Give feedback.
All reactions