[govulncheck] Generate VEX documents from `govulncheck` output

[PushkarJ]

WHAT

As part of #95 we have now setup govulncheck to run on each PR and periodically on master + stable release branches as part of verify jobs.

govulncheck has now added support for openvex: https://pkg.go.dev/golang.org/x/vuln@v1.1.2/internal/openvex

We should explore if it make sense to add VEX documents as part of each of our releases going forward.

WHY

This will partially solve the issue of k8s maintainers being requested to provide input on whether a specific CVE is affecting k/k or not by preemptively generating VEX documents for the CVEs where Kubernetes is unaffected. This will also allow us to codify the policy mentioned here: https://github.com/kubernetes/community/blob/6c75205e1b67a84d5784502dd27d1a0e04192021/contributors/devel/sig-release/cherry-picks.md?plain=1#L65

To illustrate the point, dependency updates that just aim to silence some scanners and do not fix any vulnerable code are NOT eligible for cherry-picks.

Some examples:

kubernetes/kubernetes#121370
kubernetes/kubernetes#122424
kubernetes/kubernetes#119227
kubernetes/kubernetes#122952
and many more before govulncheck was introduced

HOW

We need a trusted way to generate the VEX document, where following properties are desired:

• The VEX document is auto-generated
• The VEX document can be modified if needed by a small trusted list of k8s org members
• The VEX document can not be tampered
• The VEX document generation or modification supports non-repudiation
• The VEX document can be version controlled with git

Open to ideas on the how and we can all explore possible options together.

WHO

This would need collaboration between SIG Security, Docs, Architecture and Release.

WHERE

We may potentially host it besides https://kubernetes.io/docs/reference/issues-security/official-cve-feed/ but of course other ideas or placements are welcome!

NOTES

Part of #3, related kubernetes/kubernetes#121454

Work being Done

• Bump govulncheck to 1.1.2 kubernetes#125864
• [1.30]Bump govulncheck to 1.1.2 kubernetes#125863
• [1.29]Bump govulncheck to 1.1.2 kubernetes#125865

/sig security architecture docs release
/area dependency
/kind feature

[ritazh]

We may potentially host it besides https://kubernetes.io/docs/reference/issues-security/official-cve-feed/

+1

What are other potential places to push this artifact so scanners can automatically consume them?

[PushkarJ]

To answer Rita's question and get a sense of how the actual output looks like I tried this on k/k master and release-1.30

main branch Results

govulncheck -scan package -format openvex ./... > openvex-commit-34b8832edb00c83ba50b88ea9eefb608d3247131.out

openvex-commit-34b8832edb00c83ba50b88ea9eefb608d3247131-main.out.txt

Only 2 out of 153 CVEs were marked as affected according to govulncheck@v1.1.2 🎉

Further drilling down found the following information on both:

GO-2024-2527

GHSA-5x4g-q5rc-36jp

Being discussed as contentious / wrong: golang/vulndb#2952

CVE-2024-28180

kubernetes/kubernetes#123252

Confirmed by maintainers that this does not have security implications: kubernetes/kubernetes#123649 (comment)

release-1.30 branch results

openvex-1.30.out.txt

govulncheck -scan package -format openvex ./... > openvex-1.30.out

Only 3 out 154 CVEs were marked as affected by govulncheck@v1.1.2 🎉

2 out of 3 were identical to above

For the last remaining one found the following information:

CVE-2023-47108

Discussed and Confirmed by maintainers that this does not affect kubernetes in kubernetes/kubernetes#121842 and https://github.com/kubernetes/apiserver/issues/106#issuecomment-1952789941

Next Steps

• product field is currently undefined as per x/vuln: add support for silencing vulnerability findings with govulncheck golang/go#61211 (comment). I added a few suggestions for that: x/vuln: add support for silencing vulnerability findings with govulncheck golang/go#61211 (comment)
• As expected we will need a way to manually modify VEX documents to address and reset the above findings as "not affected"
• So it sounds like auto-generating openvex documents under a kubernetes repo and then mirroring them to k/website seems like a good idea to me.

As always open to suggestions and more feedback as we are in early stages of this discussion!

[PushkarJ]

/cc @MadhavJivrajani @dims @puerco @jeremyrickard @sftim

(For more input from SIG Architecture, Release and Docs)

[dims]

+1 for the idea with my sig-arch hat on.