According to this page go.sum may be used for dependency scanning, but is not recommended. I think it should be removed from this help page if it is not recommended. This page also seems to erroneously suggest that running go mod tidy will remove duplicate entries from go.sum, but that is not the case, because go.sum does not perform Minimal version selection (MVS)
Then, it recommends generating a go.list file. This also seems erroneous because the go list command does NOT perform Module graph pruning, and will thus report a large amount of false positives on unused transitive dependencies.
I think (since go1.17, which was EOL a while ago) the only option for dependency scanning that does not provide false positives for dependencies that are not used by an executable is to use go.mod which contains the complete list of USED dependencies and transitive dependencies.
However, I don’t think Sonatype will perform a dependency scan on go.mod, nor is this ever recommended on this page.
Hi again @jake.coddington - just wanted you to know this was passed along and our team will be working to refine the page linked here. Thank you for your feedback!
This is only partially about the documentation. The bigger portion of this topic is that there is a much better, Golang-native option that creates less scan bloat and clutter.
Why was go.mod overlooked as an SBOM option? Can we get support for go.mod?
Our manifest application analysis for “Go” is evolving and is not current with the evolution of the ecosystem, so far. However, we do support Java fingerprinting for all version upgrades.
When we added support for Go (version 1.11), we didn’t see much difference between go.sum and go.mod manifests so we made a choice of go.sum. This is also inline with Nancy.
Our team will do some investigation around adding support for go.mod.
Sorry about that - what was meant was that Java is the only ecosystem we currently have a process to keep up to date with version upgrades/changes, etc. For Go (and other manifest-supported ecosystems), we haven’t kept up to date in a similar way. So there is no relationship with Java fingerprinting updates when it comes to Go app analysis
may I know if there is place we could track on the progress?
The false positives on dependencies really confused us a lot when sonatype scanning is required in company.
We are looking forward seeing the use of go.mod on scanning!
If your company allows it, you should look in to generating an SBOM with CylconeDX. Sonatype supports scanning a CycloneDX SBOM, and it is truly way better than go.list, go.sum.
My company and the tools we use do not support using a CycloneDX SBOM, so I am unfortunately left waiting.
Hi @billy.l.t.wong! At the moment, there is not an update (though I will certainly post here in this thread if I don’t hear one) - I’m glad Jake’s suggestion has helped in the meantime!