Go Application Analysis

Evaluation: Source code and manifest analysis

The Go coordinate-based matching feature provides the ability to scan and evaluate Go module dependencies referenced in projects that use dep (Gopkg.lock) or Go modules (go.mod). Support includes Security, License, and Identity data for Go modules found on golang.org public repository.

Go Modules

Go modules is the dependency management system added to Go using a go.mod file.

Requirements for Go module analysis
A valid go.mod file is required for Go module–based dependency analysis.

Sonatype Lifecycle supports analysis using the following inputs:

• go.list
  A customer-generated file containing the output of the go list command. This provides the most accurate results because it reflects the dependencies resolved by the Go tooling during build.

• go.sum
  Supported, but may include dependencies that are not used by the application.

When using go.sum, the file must be present and valid.

When using go.sum, the go.sum file must be present and valid.

Note
These requirements apply to customer projects being scanned by Sonatype Lifecycle. The rules governing how Sonatype ingests Go modules into its intelligence data are separate and are not controlled by customer scan inputs.

Generating a go.list file
The recommended approach is to generate a go.list file using the go list command. This file should be the target for the Lifecycle scan.

go list -f '{{define "M"}}{{.Path}} {{.Version}}{{end}}{{with .Module}}  
{{if not .Main}}{{if .Replace}}{{template "M" .Replace}}  
{{else}}{{template "M" .}}{{end}}{{end}}{{end}}' -compiled -deps | sort -u > go.list

The output contains the dependency module path and version.

Example:

github.com/istio-ecosystem/authservice v1.0.1
github.com/asaskevich/govalidator v0.0.0-20200108200545-475eaeb16496

To include test-only dependencies, add the -test flag:

go list -f '{{define "M"}}{{.Path}} {{.Version}}{{end}}{{with.Module}}  
{{if not .Main}}{{if .Replace}}{{template "M" .Replace}}  
{{else}}{{template "M" .}}{{end}}{{end}}{{end}}' -test -deps | sort -u > go-test.list

Example output:

github.com/Potsdam-Sensors/OPERA-Data-Types v0.2.12
golang.org/x/mod v0.22.0
golang.org/x/text v0.20.0 <<< only used in *_test.go

Using go.sum for analysis
The go.sum file is generated and updated automatically by the Go tooling and can be used for analysis. However, it may contain module versions that are not used by the application.

Before analysis, Sonatype recommends removing unused dependencies by running:

go mod tidy

Repository coverage and Unknown components

Sonatype Lifecycle identifies Go components by matching module coordinates (module path and version) to Sonatype Go intelligence.

A Go dependency may appear as Unknown when:

• The dependency predates Go modules and the upstream repository does not contain a go.mod file.
• The dependency uses legacy or incompatible versioning patterns.

Versions containing+incompatible

Some Go versions include the suffix +incompatible (for example, v2.1.0+incompatible). These versions typically originate from repositories that predate Go modules and do not contain a go.mod file.

As a result, versions containing +incompatible may not be identified and can appear as Unknown in scan results.

To reduce the likelihood of Unknown results:

• Use a go.list file generated from your build.
• Verify whether the dependency provides a module-compatible version or alternate module path.
• Upgrade to a version that includes a valid go.mod file, when available.

Gopkg.lock (dep)

The dep dependency manager generates the Gopkg.lock file. See the Golang documentation for details.

Only [[project]] stanzas containing both name and version fields will be evaluated.

[[projects]]
  digest = "1:a2682518d905d662d984ef9959984ef87cecb777d379bfa9d9fe40e78069b3e4"
  name = "github.com/gohouse/converter"
  revision = "44968752391892e1b0d0b821ee79e9a85fa13049"
  version = "v0.0.3"

Partial Detection of Pre-Release Versions

Sonatype provides partial support for pseudo-release versions. Pseudo-versions are supported when they are used by released modules. Lifecycle analysis and Firewall quarantine may work for these versions, but coverage is not guaranteed for every pseudo version.

A pseudo-version is a special pre-release version generated by the Go tooling to reference a specific commit when no semantic version tag exists. For example:

github.com/asaskevich/govalidator
v0.0.0-20180720115003-f9ffefc3facf

This differs from a standard release version, such as:

github.com/gohouse/converter v0.0.3

Arbitrary pre-release versions that do not follow Go’s versioning rules are not supported.

• Unsupported arbitrary pre-releases are version strings that a user might manually create that look like a pre-release version, but they don't follow Go's specific rules for versioning. These versions are not generated or validated by the go command and may not work as expected in the module ecosystem.

• A pseudo-version is a special, canonical form of a pre-release version generated by the go command. It is a supported way to refer to a specific commit in a version control system when there is no semantic version tag. The format is strictly defined to ensure consistency, validation, and proper sorting.

Steps to analyze using the Sonatype Lifecycle CLI

Run a scan

Invoke a CLI scan of a directory or subdirectories containing go.list, go.sum or go.list files.

Example go.sum file

github.com/istio-ecosystem/authservice v1.0.1
h1:xyM0XyhRQUsf2Y0lEABbOHvLDVjiRkjTxi+dza87M80=
github.com/istio-ecosystem/authservice v1.0.1/go.mod
h1:Yb3eAs+8j4rYcnthK6iK9e/3HDZJ5C2PsYaugkeQR2I=
github.com/gohouse/gorose v1.0.5
h1:Iescp+mt88bkIXqmTF2ixM4nlLjo6D9CXX6hRWCz2lc=
github.com/gohouse/gorose v1.0.5/go.mod
h1:eGB2F605oLiIpo14y0o1EvBWXQ6h0hgW3OMhGJtwk8Y=

Steps to analyze using the Jenkins plugin

By default, the Jenkins plugin will not evaluate the Gopkg.lock, go.sum, and go.list files. A custom Scan Target is needed.

Example Pipeline Script with Scan Patterns

nexusPolicyEvaluation iqApplication: 'SampApp',
 iqScanPatterns: [[scanPattern: '**/Gopkg.lock'], [scanPattern: '**/go.sum'],\
 [scanPattern: '**/go.list']], iqStage: 'build'

Steps to analyze using the Bamboo plugin

Bamboo Scan Targets control what files are examined. To evaluate Go, add Gopkg.lock, go.sum, and go.list to the scan targets via a comma-separated list e.g.

Example Bamboo Scan Patterns

**/Gopkg.lock,**/go.sum,**/go.list

Search results

No results found