How to act on go-module vulnerabilities?

[Aqualon]

We just started looking into gryp to scan our docker images and for a ruby-on-rails project running on Ubuntu Jammy we get a lot of go-related vulnerabilities shown:

stdlib                 go1.18.5                             1.21.11, 1.22.4         go-module  CVE-2024-24790       Critical    
stdlib                 go1.18.5                             1.19.10, 1.20.5         go-module  CVE-2023-29405       Critical    
stdlib                 go1.18.5                             1.19.10, 1.20.5         go-module  CVE-2023-29404       Critical    
stdlib                 go1.18.5                             1.19.10, 1.20.5         go-module  CVE-2023-29402       Critical    
stdlib                 go1.18.5                             1.19.9, 1.20.4          go-module  CVE-2023-24540       Critical    
stdlib                 go1.18.5                             1.19.8, 1.20.3          go-module  CVE-2023-24538       Critical    
stdlib                 go1.18.5                             1.21.0-0                go-module  CVE-2023-24531       Critical    
stdlib                 go1.18.5                             1.22.7, 1.23.1          go-module  CVE-2024-34158       High        
stdlib                 go1.18.5                             1.22.7, 1.23.1          go-module  CVE-2024-34156       High        
stdlib                 go1.18.5                             1.21.12, 1.22.5         go-module  CVE-2024-24791       High        
stdlib                 go1.18.5                             1.21.8, 1.22.1          go-module  CVE-2024-24784       High        
stdlib                 go1.18.5                             1.21.9, 1.22.2          go-module  CVE-2023-45288       High        
stdlib                 go1.18.5                             1.20.0                  go-module  CVE-2023-45287       High        
stdlib                 go1.18.5                             1.20.12, 1.21.5         go-module  CVE-2023-45285       High        
stdlib                 go1.18.5                             1.20.10, 1.21.3         go-module  CVE-2023-44487       High        
stdlib                 go1.18.5                             1.20.9, 1.21.2          go-module  CVE-2023-39323       High        
stdlib                 go1.18.5                             1.19.10, 1.20.5         go-module  CVE-2023-29403       High        
stdlib                 go1.18.5                             1.19.9, 1.20.4          go-module  CVE-2023-29400       High        
stdlib                 go1.18.5                             1.19.9, 1.20.4          go-module  CVE-2023-24539       High        
stdlib                 go1.18.5                             1.19.8, 1.20.3          go-module  CVE-2023-24537       High        
stdlib                 go1.18.5                             1.19.8, 1.20.3          go-module  CVE-2023-24536       High        
stdlib                 go1.18.5                             1.19.8, 1.20.3          go-module  CVE-2023-24534       High        
stdlib                 go1.18.5                             1.19.6                  go-module  CVE-2022-41725       High        
stdlib                 go1.18.5                             1.19.6                  go-module  CVE-2022-41724       High        
stdlib                 go1.18.5                             1.19.6                  go-module  CVE-2022-41723       High        
stdlib                 go1.18.5                             1.18.7, 1.19.2          go-module  CVE-2022-41715       High        
stdlib                 go1.18.5                             1.18.7, 1.19.2          go-module  CVE-2022-2880        High        
stdlib                 go1.18.5                             1.18.7, 1.19.2          go-module  CVE-2022-2879        High        
stdlib                 go1.18.5                             1.18.6                  go-module  CVE-2022-27664       High        
stdlib                 go1.18.5                             1.21.11, 1.22.4         go-module  CVE-2024-24789       Medium      
stdlib                 go1.18.5                             1.21.10, 1.22.3         go-module  CVE-2024-24787       Medium      
stdlib                 go1.18.5                             1.20.12, 1.21.5         go-module  CVE-2023-39326       Medium      
stdlib                 go1.18.5                             1.20.8, 1.21.1          go-module  CVE-2023-39319       Medium      
stdlib                 go1.18.5                             1.20.8, 1.21.1          go-module  CVE-2023-39318       Medium      
stdlib                 go1.18.5                             1.19.12, 1.20.7         go-module  CVE-2023-29409       Medium      
stdlib                 go1.18.5                             1.19.11, 1.20.6         go-module  CVE-2023-29406       Medium      
stdlib                 go1.18.5                             1.19.7, 1.20.2          go-module  CVE-2023-24532       Medium      
stdlib                 go1.18.5                             1.18.9, 1.19.4          go-module  CVE-2022-41717       Medium      
stdlib                 go1.18.5                             1.22.7, 1.23.1          go-module  CVE-2024-34155       Unknown     
stdlib                 go1.18.5                             1.21.8, 1.22.1          go-module  CVE-2024-24785       Unknown     
stdlib                 go1.18.5                             1.21.8, 1.22.1          go-module  CVE-2024-24783       Unknown     
stdlib                 go1.18.5                             1.21.8, 1.22.1          go-module  CVE-2023-45290       Unknown     
stdlib                 go1.18.5                             1.21.8, 1.22.1          go-module  CVE-2023-45289       Unknown 

To our understanding so far, this probably means that something was built using go 1.18.5 compiler, because we don’t have the go compiler installed in the docker image.

What we don’t get yet is, can we do anything about it?

[willmurphy]

Hi @Aqualon this is a great question! Thanks for asking it.

You’re absolutely right, what Grype is telling you is that there is a Go program in your image that was built with Go 1.18.5, which has a number of CVEs. Of course, every Go executable has the dependency “stdlib” so that package name isn’t very helpful.

We do have an experimental command to help: grype explain.

Right now, grype explain takes the scan results on stdin, so for example you could do this:

$ grype -o json $MY_IMAGE > /tmp/grype.json
$ cat /tmp/grype.json | grype explain --id CVE-2023-24537

This will print a lot of info about the vulnerability, including the locations where a vulnerable package is found.

You could also use jq to just get the locations and IDs all at once:

$ cat /tmp/grype.json | jq -c '.matches[] | select(.artifact.name == "stdlib") | { path: .artifact.locations[0].path, id: .vulnerability.id }' | sort | uniq

As for what to do about it, you could try upgrading the vulnerable package once you know where it is - maybe there’s an upgrade available from your distro? It really depends what the vulnerable package is. Maybe it makes sense for you to remove it, or see if a newer version is present in a newer base image.

I’ll add this question to our topic list for our livestreamed community gardenings, since I think this is a place in our UX where we could be doing better.

Thanks for the great question!

[Aqualon]

@willmurphy

cat /tmp/grype.json | jq -c '.matches[] | select(.artifact.name == "stdlib") | { path: .artifact.locations[0].path, id: .vulnerability.id }' | sort | uniq

That helped a lot, could figure out it was a custom built package we use, that is written in go and was built in go 1.18.5, also confirmed via go itself

go version -m /usr/bin/olympic-runner 
/usr/bin/olympic-runner: go1.18.5