Go Integration

Overview

The Unified Agent detects Go dependencies via two different resolvers:

• A specific resolver for detecting Go Modules dependencies.

• A generic resolver for detecting dependencies defined by the other Go package managers: Dep, Godep, Vndr, Gogradle, Govendor, Gopm, Glide.

NOTE: Before you begin, make sure that the relevant package managers are installed. For details, see https://docs.mend.io/legacy-sca/latest/getting-started-with-the-unified-agent#GettingStartedwiththeUnifiedAgent-Prerequisites .

Configuration

Both Go resolvers expose different parameter sets to control them:

• Configuration parameters for controlling the Go Modules resolver can be found here.

• Configuration parameters for controlling the generic Go resolver can be found here.

Examples

Go Modules

Go Modules dependencies are detected using the designated resolver, which is based on the Modules manifest file go.mod and requires the Go binary.

The Go Modules resolver is enabled by default, using the following setting: 

go.modules.resolveDependencies=true   

Godep

Godep dependencies are detected using the generic Go resolver, which is based on the Gopkg.lock file.

The following settings can be used for Godep: 

go.resolveDependencies=true   
go.collectDependenciesAtRuntime=false
go.dependencyManager=godep

Glide

Glide dependencies are detected using the generic Go resolver, which is based on the glide.yaml file.

The following settings can be used for Glide: 

go.resolveDependencies=true   
go.dependencyManager=glide
go.glide.ignoreTestPackages=false

Go Modules Resolver

The Go Modules resolver detects only the actively-used dependencies in a full dependencies hierarchy. It is based on the Modules manifest file go.mod and requires the Go binary.

Generic Go Resolver

Using the go.collectDependenciesAtRuntime parameter

Setting the go.collectDependenciesAtRuntime parameter to control the generic Go resolver will have a different effect, depending on the Go package manager in use.

Godep, Vndr, and Dep

When the following conditions are met:

• The go.collectDependenciesAtRuntime is set to true.

• The dependency file is available.

• The vendor folder is missing.

The following is performed:

1. For Vndr and Dep, the existing dependency file will be renamed in the following format: <dependency_file>-<YYYY.MM.DD>T<HHmmss>+<UTC offset>.<extension> and the pre-step command will be executed.

2. For Godep, the existing Godeps folder name will be renamed in the following format: Godeps-<YYYY.MM.DD>T<HHmmss>+<UTC offset> and the pre-step command will be executed.

3. For all three noted package managers, the vendor folder containing all the relevant dependencies/files will be created. A new dependency file will also be generated.

Govendor

When setting the go.collectDependenciesAtRuntime to true, if the govendor fetch command was executed prior to the scan on the relevant project, the dependencies will be downloaded and the scan results will include a full hierarchy tree. Otherwise, the scan will result in a flat dependencies list.

Glide

The go.collectDependenciesAtRuntime parameter is irrelevant for the Glide package manager.

Known Limitations

The generic Go resolver provides support for a hierarchy tree for the following packages: Glide, Gopm, Godep, Dep, Govendor and Vndr.
For Gogradle, the direct and transitive dependencies are displayed in a flat structure.

In order to support the retrieval of a project's full hierarchy tree, one of the following requirements must be met:

• The dependency file and vendor folder are available in the project.

• The go.collectDependenciesAtRuntime parameter is set to true and the relevant dependency manager is installed.