The only file for Open Source scans with Golang is NOT supported

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 you’d need to ask in the IQ forum, this is for topics related to the Repository Manager

1 Like

Moving to the IQ category for visibility!

1 Like

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!

Hey @mfrost

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?



Let me go back and see if I can get that answer!

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.

1 Like


That backstory makes a lot of sense for why decisions were made to use go.sum and go.list. Go modules have changed a LOT from 1.11 to 1.17 (and on).

Thanks for looking into go.mod, I think you’ll find some good results.

I’m not sure what Java fingerprinting would be when applied to Go. Is that just a format for manifests/SBOMs?

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

1 Like

I see, thanks for the clarification

1 Like

Hi @mfrost

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.

1 Like

Thank you for the suggestion!
It is allowed in my company.
It really help for resolving the false positive!

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!