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

Sonatype Lifecycle & Repository Firewall Best Practices
1

https://help.sonatype.com/iqserver/analysis/go-application-analysis

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.

2

Hi you’d need to ask in the IQ forum, this is for topics related to the Repository Manager

1 Like
3

Moving to the IQ category for visibility!

1 Like
4

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!

5

Hey @mharwood

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?

Thanks,

Jake

6

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

7

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
8

@mharwood

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.

9

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

10

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
11

I see, thanks for the clarification

1 Like