# 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](https://index.golang.org/index) 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](https://golang.github.io/dep/docs/Gopkg.lock.html) 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