x/vuln: add support for suppressing vulnerabilities by ID

[bentcoder]

What version of Go are you using (go version)?

$ go version
go version go1.20.2 darwin/amd64

What operating system and processor architecture are you using (go env)?

go env Output

$ go env
MacOS amd64 darwin

Hi,

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

$ govulncheck -config vuln.yaml ./...

# vuln.yaml
vulnerability:
    exclude:
        - GO-2023-1704
        - GO-2023-1705

Flag

$ govulncheck \
    -exclude GO-2023-1704 \
    -exclude GO-2023-1705 \
    ./...

[tianon]

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:

[paveljanda]

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. 👍

[silverwind]

This would be useful for cases like https://pkg.go.dev/vuln/GO-2024-2698 which has "no known fix".

[ldemailly]

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?)

[dornimaug]

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.

[MalteMagnussen]

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.

[jameinel]

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.

[AlexanderYastrebov]

There is PR https://github.com/golang/vuln/pull/7 that implements this feature. @zpavlinovic suggests that this feature needs a proposal.

[zpavlinovic]

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.