-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Integrate govulncheck #9091
Comments
This issue is currently awaiting triage. If CAPI contributors determines this is a relevant issue, they will accept it by applying the The Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
Example how When taking a look at today's main branch commit Importing vulnerable package but not affected:Example vulnerability/CVE: https://pkg.go.dev/vuln/GO-2023-1988 govulncheck is able to detect that we are not affected. output from
Vulnerability in used go sdk versionNote: If I am right, this is something which does not get detected by trivy (cc @sbueringer) Note2: To detect go sdk dependent CVE's, Example output for a CVE where we are affected and bumping the used go sdk to a newer version would fix the issue:
In this case main is affected by the vulnerability (note: in reality not, because we bumped go in our CI, just on my local test). Bumping go to >= 1.20.6 would fix the CVE. |
Overall I like the idea, and +1 to:
We have to make sure to document if it needs any update the same way as Trivy as part of release tasks (https://github.com/kubernetes-sigs/cluster-api/blob/main/docs/release/release-tasks.md#setup-jobs-and-dashboards-for-a-new-release-branch) |
Thx for testing this and reporting
I think you're right. Just tested it by changing the GO_VERSION in the Makefile to 1.20.0 and running I would be in favor to add this to |
As follow-up step of integrating this we could automate to not fail if there are only trivy false-positives which are identified via govulncheck. |
I would prefer not doing this for the foreseeable future. Up until now whenever we found a CVE we could fix it by bumping a dependency (and now also the Go SDK). So I don't want to start ignoring Trivy findings until we have to. (I mostly see this as finding more CVEs (e.g. in the Go SDK) & additional info to assess the impact of a CVE, I would like to bump independent of that) |
/assign |
govulncheck is a tool provided by the Go team: https://go.dev/blog/vuln
It allows scanning Go code for vulnerabilities and then reports if the vulnerable code is actually used (it could be that we have a Go Dependency with a CVE, but the affected package in the dependency is not actually used). The huge benefit here is that it can help to assess the impact of CVE's (i.e. no impact if we don't use the code).
It should be pretty easy to integrate as it can be ~ run via
go run golang.org/x/vuln/cmd/govulncheck ./...
. But let's integrate it with go install like other tools.Limitations:
Notes:
The text was updated successfully, but these errors were encountered: