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

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.

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.

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.

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.

@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!

Change https://go.dev/cl/575857 mentions this issue: internal/vex: add vex types

Change https://go.dev/cl/575860 mentions this issue: internal/vex: add hash for doc ID

Change https://go.dev/cl/575858 mentions this issue: internal/vex: add handler