Open bentcoder opened 1 year ago
In my case, I'm wanting this because govulncheck
is now reporting GO-2023-1840
(https://pkg.go.dev/vuln/GO-2023-1840) on my binaries, but I've already got my own mitigation code for setuid
bits being set, so the vulnerability doesn't really apply (which is the whole reason I love govulncheck
- it normally is very good at filtering out things that don't apply, but in this case it really can't know :heart:). :disappointed: :sweat_smile:
We would love to support this solution. 👍
In our case, our pipelines are set to fail if govulncheck fails. That being said, not all govulncheck errors are necessarily related to our production code use-cases.
Is kind of an industry standard to make false-positives ignored in vulnarability checks, static code analysis tools etc.
Thx. 👍
This would be useful for cases like https://pkg.go.dev/vuln/GO-2024-2698 which has "no known fix".
What's an example of vulnerability flagged by govulncheck yet not actually in a reachable code path? that seems would be a bug in govulncheck, not something to exclude but something to fix (if there is such a thing?)
What's an example of vulnerability flagged by govulncheck yet not actually in a reachable code path? that seems would be a bug in govulncheck, not something to exclude but something to fix (if there is such a thing?)
https://pkg.go.dev/vuln/GO-2024-2994 is such an example. Just importing k8s.io/kubernetes/pkg/apis/core from a vulnerable version flags this on every OS apparently because of the init function in core being this code path identified by govulncheck. I don't know if this is actually theoretically reachable code, but there are many scenarios where it is practically impossible to reach it, for example any kind pure k8s client use.
https://pkg.go.dev/vuln/GO-2024-2746 is basically the same kind of example.
We'd love to be able to suppress all windows vulnerabilities.
We never deploy to windows, so seeing those vulns are simply noise for us.
We have a common pattern of a "stable release" that is supported with security fixes only, that ends up in that state for a number of years. Having a tool like govulncheck is ideal, because it lets us be aware that there might be a security issue, but we also need a way to acknowledge that this particular issue does not warrant a Major.Minor compiler update. However, we don't want to skip doing the check entirely, because a new issue on the compiler might very much warrant the effort.
Having a clear way to record issues that you've acknowledged, but still see ones that you haven't seen before is very useful.
There is PR https://github.com/golang/vuln/pull/7 that implements this feature. @zpavlinovic suggests that this feature needs a proposal.
We are actively working on this feature. We don't have an exact timeline, but there won't be a need for a proposal. We plan to use OpenVex format for specifying vulnerability info for filtering.
What version of Go are you using (
go version
)?What operating system and processor architecture are you using (
go env
)?go env
OutputHi,
Requesting to introduce a config file (ideally) or a flag that allows users to explicitly exclude some vulnerabilities? Maybe until they resolve them, they can be suppressed in CI so on.
Thanks
Config file
Flag