Skip to content
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

Time to upgrade golang, there are quite a few HIGH findings in kubeconform v0.6.4 #263

Closed
bobrasey-verusen opened this issue Mar 22, 2024 · 8 comments

Comments

@bobrasey-verusen
Copy link

We build a container image based on this project, and AWS Inspector is showing quite a few HIGH findings, all centered around golang generally, and many of them involving net and grpc specifically. Seems like bumping golang version and imports is due.

@yannh
Copy link
Owner

yannh commented May 9, 2024

Updated to the latest Go version supported by goreleaser (1.22.1), release coming up. Could you point me to the issues you're referencing?

@bobrasey-verusen
Copy link
Author

Sure, I have a view via AWS Inspector since I'm putting my images in ECR and there's a lot of good summary info there that I can't provide you a link to. But I can send you some of the upstream links - they're harder to read but hopefully can provide you with some context.

CVE-2023-44487 - golang.org/x/net, google.golang.org/grpc and 1 more
GHSA-m425-mq94-257g - google.golang.org/grpc
CVE-2022-41723 - golang.org/x/net
CVE-2023-39325 - golang.org/x/net, golang.org/x/net

Summing up the remediation steps, this should clear these:

  • Update golang.org/x/net to 0.17.0
  • Update google.golang.org/grpc to 1.58.3

These are all the HIGH findings associated with golang that I see. Also, I am modifying your kubeconform image a tiny bit, but I don't think that would affect these findings.

Let me know if there's anything else I can do to help.

@bobrasey-verusen
Copy link
Author

Also, let me put in a plug for Snyk here, they have a limited-use free license and it's a fantastic tool for stuff like this. Here's a sample finding for this use case:

Screenshot 2024-05-09 at 10 17 36 AM

@yannh
Copy link
Owner

yannh commented May 9, 2024

Fun fact, I believe the original Kubeval author now actually works at Snyk :) I'm not very familiar with their free tier. How would you suggest configuring this though - failing a build if there are vulnerabilities? Running it periodically on master? Running it periodically on all published images? 🤔 I can imagine it would be quite useful to run this on the versions you are actually using, but I'd love your advice on its usage in the toolchain.

@yannh
Copy link
Owner

yannh commented May 9, 2024

Tagged v0.6.5 btw, hope it fixes the issues.

@bobrasey-verusen
Copy link
Author

I haven't scanned containers in a pipeline using Snyk, but it's apparently doable. Now you have me thinking about doing this for my stuff...

@bobrasey-verusen
Copy link
Author

I didn't really answer your question... I am currently only security scanning container images once they are pushed to a repo. In practice this is fine, we have tooling that surfaces vulnerabilities to us and we respond within an SLA based on severity. Scanning in the pipeline would catch things sooner, which is why I'm considering it now, but honestly what we have is working Good Enough.

The limitation you'll run into with Snyk is how many times you can run a type of test when using the free tier. Looks like it's 100 container tests per month, so maybe that's enough for you?

Pricing

@bobrasey-verusen
Copy link
Author

Also, TIL kubeval was started by Gareth Rushgrove! I had no idea.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants