search

kubernetes / sig-security

Process documentation, non-code deliverables, and miscellaneous artifacts of Kubernetes SIG Security
Apache License 2.0
166 stars 55 forks source link

[govulncheck] Generate VEX documents from `govulncheck` output #116

Open PushkarJ opened 3 months ago

PushkarJ commented 3 months ago

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:

https://github.com/kubernetes/kubernetes/issues/121370 https://github.com/kubernetes/kubernetes/issues/122424 https://github.com/kubernetes/kubernetes/issues/119227 https://github.com/kubernetes/kubernetes/issues/122952 and many more before govulncheck was introduced

HOW

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

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 https://github.com/kubernetes/kubernetes/issues/121454

Work being Done

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

ritazh commented 3 months ago

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 commented 3 months ago

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

https://github.com/etcd-io/etcd/security/advisories/GHSA-5x4g-q5rc-36jp

Being discussed as contentious / wrong: https://github.com/golang/vulndb/issues/2952

CVE-2024-28180

https://github.com/kubernetes/kubernetes/issues/123252

Confirmed by maintainers that this does not have security implications: https://github.com/kubernetes/kubernetes/pull/123649#issuecomment-1975021556

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 https://github.com/kubernetes/kubernetes/pull/121842 and https://github.com/kubernetes/apiserver/issues/106#issuecomment-1952789941

Next Steps

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

PushkarJ commented 2 months ago

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

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

dims commented 2 months ago

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

puerco commented 2 months ago

+1 with my releng hat on!

@PushkarJ: I added some views on govulncheck about the missing product, I think we can fix it by sending a couple of patches to govulncheck.

Also, I read your comment there about the multiple products. Don't worry about it, once we have the source openvex document, we can enhance it to include the rest of the release artifacts by pulling in data from the SBOMs.

This is super exciting :tada:

puerco commented 2 months ago

@ritazh we should also sign them and attach them to container images. Grype will soon autodiscover them there. We are also working on a specification to host the vex data in the repositories (see https://github.com/openvex/spec/issues/46 )