This is a tracking issue to add support for silencing vulnerability findings with govulncheck.
59507 is related.
Comment From: rikatz
@julieqiu is there someone working on this feature? Otherwise, I can try working on something to support this exclude flag :) Not sure I am the best person to, but happy to help!
Comment From: zpavlinovic
Although we don't currently have a plan of adding support for it, we thought if we add it then we'll use OpenVex format. This is also a recently added format for the output of govulncheck. Would OpenVex format work for what you are trying to suppress?
Comment From: rikatz
not sure, tbh I don't know almost anything on OpenVex.
My use case is simpler, this false positive started to appear and I need to ignore it on my pipelines while this is not fixed on DBs :)
So is more like a "skip CVE" (a la go test -skip)
Comment From: tianon
OpenVEX is workable here, but kind of annoying for the same reasons the current output format struggles with: defining an appropriate purl is hard (I suppose worst case we could use a bogus placeholder, like govulncheck itself is doing)
If we were to provide an input VEX, what would the VEX output look like? Would it just copy entries from the input verbatim for the output where relevant?
Comment From: zpavlinovic
So is more like a "skip CVE" (a la go test -skip)
Then OpenVex is fine here.
OpenVEX is workable here, but kind of annoying for the same reasons the current output format struggles with: defining an appropriate purl is hard (I suppose worst case we could use a bogus placeholder, like govulncheck itself is doing)
We are in the process of figuring out the product fields for OpenVex. That would need to be done first.
If we were to provide an input VEX, what would the VEX output look like? Would it just copy entries from the input verbatim for the output where relevant?
From the top of my head, we would take the not_affected and skip analyzing for those. Everything else would be the same I guess. I would have to think more.
Comment From: PushkarJ
@zpavlinovic Suggestion on product fields:
- It might make sense to default it to module name in go.mod file e.g. https://github.com/kubernetes/kubernetes/blob/master/go.mod#L7
- It would also be super-useful to allow users to define a comma-listed list of products. For example, in case of kubernetes, all the code in core kubernetes is in k/k but we would like to add all the core k8s release images under product potentially. This is mainly because scanners that will consume openvex output will be run on release images by end users
Comment From: PushkarJ
Btw, for anyone trying this out for their golang projects, shared a few experiments with k/k here: https://github.com/kubernetes/sig-security/issues/116#issuecomment-2197995745
Comment From: zpavlinovic
@zpavlinovic Suggestion on product fields:
- It might make sense to default it to module name in go.mod file e.g. https://github.com/kubernetes/kubernetes/blob/master/go.mod#L7
This seems to be in stark contrast to what has been recently proposed.
IMO, what is proposed there makes more sense.
- It would also be super-useful to allow users to define a comma-listed list of products. For example, in case of kubernetes, all the code in core kubernetes is in k/k but we would like to add all the core k8s release images under product potentially. This is mainly because scanners that will consume openvex output will be run on release images by end users
I think it is best for users to post-process the govulncheck output themselves. Customizing the output can turn into a rabbit hole with flags and different user needs.
Comment From: puerco
Hey all I am one of the OpenVEX maintainers. Thanks for getting this discussion going!
I added some comments about the product/subcomponent values over in https://github.com/golang/go/issues/68152#issuecomment-2216458381
The TLDR: As @PushkarJ suggests the product, when govulncheck is looking at the source, the product should be the package URL (purl) of the main module. And the dependency with the vulnerability would go in the subcomponent.
When it comes to analyzing a binary, just use a file: URI but specify the file hashes. Our tooling will prefer them when matching with data SBOMs, etc that content-addresses artifacts with hashes. This gets rid of using purls for binaries as @tianon correctly mentioned above. We prefer not using a purl in a case like this.
See the examples on the comment in #68152
Comment From: arvenil
Another wrong report blocks pipelines for days and results in bunch of open issues for GO-2025-3829: https://github.com/golang/vulndb/issues/3860 https://github.com/golang/vulndb/issues/3879 https://github.com/golang/vulndb/issues/3880 https://github.com/golang/vulndb/issues/3882 https://github.com/golang/vulndb/issues/3883