Go for open source
Since January 1, 2023, Snyk has not supported govendor Projects. As a general security best practice, Snyk recommends using tools that are consistently maintained and up-to-date.
Since Snyk no longer supports scanning of govendor Projects, a warning is issued and no results are provided.
Go for Snyk Open Source support
Supported Go versions
Snyk supports all versions of Go, including the latest stable version listed on the Go All releases page.
Refer to the Go details for supported package manager and features.
Only official releases are tracked. Commits, including into the default branch, are not identified unless included in an official release or tag.
In the case of projects that have a package manager, this means a release to the package manager.
In the case of Go and Unmanaged scans (C/C++) this requires an official release or tag on the GitHub repo.
Go Modules and dep support
Feature availability Some features may not be available, depending on your plan. For more information, see Plans and pricing.
Snyk supports testing and monitoring of Go Projects with dependencies managed by Go Modules and dep.
Go Modules and the CLI
Snyk scans Go Modules Projects in the CLI at the package level rather than the module level, as Snyk has full access to your local source code.
Packages from the Go standard library are not supported or included in the dependency tree.
Packages under golang.org/x/
that are part of the Go Project but outside the main Go tree are supported.
To build the dependency tree, Snyk uses the go list -json -deps ./...
command, and the dependencies found in Imports
.
TestImports
and XTestImports
are not supported.
When you test Go Modules Projects using the CLI, Snyk does not require that their dependencies are installed, but you must have a go.mod
file at the root of your Project. go list
uses this and your Project source code to build a complete dependency tree.
Different versions of Go generate different results for the go list -json -deps
command. This can affect the dependency tree and the vulnerabilities that the Snyk CLI finds.
Dep and the CLI
To build the dependency tree, Snyk analyzes your Gopkg.lock
files.
When you test dep Projects using the CLI, Snyk requires installation of dependencies. Run dep ensure
to achieve this.
Dep and Git
To build the dependency tree, Snyk analyzes the Gopkg.lock
files in your Git repository.
Go Modules and Git
By default, dependencies for Go Modules Projects imported using Git are resolved at the module level rather than the package level, as with Projects tested in the CLI. Thus, when importing using Git, you may see more dependencies and issues reported, including potential false positives, than with the CLI.
To obtain the best possible resolution, enable full source code analysis.
When full source code analysis is enabled, Snyk uses the go list -json -deps ./...
command to build the dependency tree the same way the CLI test does. Otherwise, it uses go mod graph
.
Enable full source code analysis
To build the most accurate dependency tree for Go Modules Projects imported from Git, Snyk needs to access all the files in your repository.
This enables Snyk to see the import
statements in your .go
source files, and determine which specific packages are used in your application. Without this access, Snyk will include all packages from the modules listed in your go.mod
file.
To enable full source code analysis, adjust your settings as follows:
Log in to your account and select your Group and Organization.
Navigate to Settings, then Languages.
Select Edit settings for Go.
Toggle full source code analysis on or off.
For more details on levels of access to your repository required by different Snyk features, see How Snyk handles your data.
Private modules
Go modules Projects that rely on modules from private Git repositories are supported if those repositories are in the same Git organization as the main project repository.
If you have private modules in repositories from other Git organizations, your Project imports may not work properly. The same is true if your code uses Git Submodules from another organization.
If your private modules have other private modules from another Git organization, your Project imports will not work. All private modules, including the ones within other modules, need to be part of the same Git organization as the main project repository.
Private module support in different SCMs varies depending on whether full source code analysis is enabled or disabled.
Azure Repos
Bitbucket Cloud
Bitbucket Server
GitHub
GitLab
GitHub Enterprise
Bitbucket Cloud
GitHub
GitHub Enterprise
Snyk Broker support for GO
Snyk Broker is supported only when full source code analysis is disabled
Go Modules Projects imported using new Snyk Broker clients should work as expected.
To add support to clients created before December 30, 2020, add go.mod
and go.sum
to your accept.json
file, as per the changes in this pull request.
If you're using private Go Modules integrated through the Broker, each private module must have a go.mod
file defined.
Last updated