x/vuln: Add option to govulncheck to output VEX statement

[eliaslevy]

govulncheck is a more accurate Go vulnerability scanner than available alternatives because it performs static analysis to eliminate vulnerabilities in dependencies that are not reachable by application code. This reduces a large number of application vulnerability false positives. While helpful in reducing first-party vulnerability management toil, the false positive information must be conveyed to third-parties in a machine readable way to reduce the toil caused by vulnerability inquiries from third-parties with less accurate scanners.

govulncheck should implement an option that instructs it to create a VEX statement with the vulnerabilities it found, but equally as important, the vulnerabilities it found were not applicable because the code is not reachable.

Output could be in the CSAF v2 format.

[zpavlinovic]

@ianthehat

[ianthehat]

There are lots of possible formats, rather than trying to add them all into govulncheck we designed the json output to provide enough information to build those integrations externally.
The intention is to support VEX through a separate tool, that reads and writes VEX documents. It will use govulncheck underneath, processing the output to detect if the VEX document is up to date.
I have a prototype of the VEX integration (in collaboration with engineers working on VEX itself at Google), when I finish it I will publish it for general use, and as an example for how people can build other integrations rather than relying on us to implement them all.

[wespanther]

Thanks for the update @ianthehat, that makes a lot of sense and it's great to hear you're working on this.

we designed the json output to provide enough information to build those integrations externally.

One question on this point - right now the --json option to govulncheck only includes the detected vulnerabilities and the information related to the trace. With this VEX integration, would it also include the vulnerabilities that were not detected (i.e. CVEs in the given go toolchain or module versions that are not present)? I think it would have to, but wanted to clarify.

[ianthehat]

It does already include that information, although we think there are cases it misses that we are fixing.
If you see a finding where the trace has no package or symbol information, then it means that vulnerability was in the require graph but not called in the code for instance.

One thing I am trying to work out is whether we really want a tool that writes VEX “not affected” statements directly from the govulncheck json (the thing I have been prototyping), or wether the ecosystem needs a more general tool that can infer those VEX statements from a SARIF file. We need to support conversion to SARIF anyway, and I believe SARIF allows for a representation of vulnerabilities that are checked but not present (results with kind = "pass"), which might be sufficient for a much more general purpose tool, rather than one that only works for go.

[micahhausler]

I have a prototype of the VEX integration (in collaboration with engineers working on VEX itself at Google), when I finish it I will publish it for general use, and as an example for how people can build other integrations rather than relying on us to implement them all.

@ianthehat I'd be very interested in such a tool. Is this something you're open to collaboration on? Any reason to keep it private until its finished?

One thing I am trying to work out is whether we really want a tool that writes VEX “not affected” statements directly from the govulncheck json

This is a use case I know would be valuable. Coming at this as a Kubernetes security maintainer and a security professional, I regularly see user reports that include outputs from commercial scanning tools that flag unaffected Go dependencies, and want a way to confidently point to lack of impact.

[zpavlinovic]

Thanks for the update @ianthehat, that makes a lot of sense and it's great to hear you're working on this.

we designed the json output to provide enough information to build those integrations externally.

One question on this point - right now the --json option to govulncheck only includes the detected vulnerabilities and the information related to the trace. With this VEX integration, would it also include the vulnerabilities that were not detected...

I just want to point out that we recently added extra information to govulncheck JSON that allows one to figure out what vulnerabilities were not detected.

govulncheck streamed JSON will 1) generate information about every OSV for modules used by the program (not taking into account their version information yet) and then 2) produce findings for each precision level (module, package, symbol) as it goes along. Say you are calling govulncheck JSON in symbols mode. If you see a package-level finding for a vulnerability V, but not a symbol-level finding, then you know V has been imported but not called.

We continue working on the VEX support.

[wespanther]

@zpavlinovic - excellent, exactly what I was looking for. Running a simple test with govulncheck v1.0.3 seems to confirm the findings in the json output. Thanks for the update!