You can find vulnerabilities in your Go applications using Veracode Software Composition Analysis agent-based scanning. You can run a scan on Glide, go get, Go modules, Godep, Govendor, and Trash repositories using the agent-based scanning command-line interface or the CI integrations.
For packaging instructions for Veracode Static Analysis and Veracode SCA upload scans, see Packaging Go Applications.
Requirements
Scanning a repository that utilizes Go and one of its build/package managers requires the ability to assemble the project dependencies within the environment you intend to scan the project in.
Go Requirements
- Meet the requirements for the Veracode SCA agent.
- Use Go version 1.5 or later.
- Ensure that the project can build in the environment where the agent performs scans.
- Ensure that the GOROOT and GOPATH environment variables are set to the correct directories, and that the bin subdirectory of GOROOT is included in the PATH environment variable. For example, if GOROOT is set to /usr/local/go, you should include /usr/local/go/bin in your PATH. See the Go documentation for more information on configuring Go projects.
- If you use Godep, Govendor, Glide, or Trash, ensure the package manager is installed.
- For these tools, meet the specified requirement:
- Glide: include the Glide.lock file
- Go get: use Go version 1.5–1.15
- Go modules: run the 'go list -m all' command
- Godep: include the Godeps/Godeps.json file
- Golangdep: include the Gopkg.lock file
- Govendor: include the vendor/vendor.json file
- Trash: include the vendor.conf file
You can use agent-based scanning to scan any code repository which you have access to and fulfills the above requirements. To demonstrate how to run a scan, you can clone one of the Veracode SCA public repositories:
Glide
git clone https://github.com/srcclr/example-go-glide
Go Get
git clone https://github.com/srcclr/example-go-goget
Go Modules
git clone https://github.com/srcclr/example-go-modules
Godep
git clone https://github.com/srcclr/example-go-godep
Govendor
git clone https://github.com/srcclr/example-go-govendor
Trash
git clone https://github.com/srcclr/example-go-trash
# Replace "example-go" with the project folder name of your choosing srcclr scan path/to/example-go-goget
To view more verbose output during the scan process, you can add the --loud argument as well:
srcclr scan path/to/example-go-goget --loud
The Veracode SCA agent then proceeds to use the native package managers in order to identify the dependencies and their versions in your project. The command used varies depending on the build or package manager. These commands only run if the environment variable SRCCLR_FORCE_GO_INSTALL is set to true (or FORCE_GO_INSTALL: true in srcclr.yml) or --url is used:
Go Get
go get -d ./...
Glide
glide install
GoDep
godep restore
GoVendor
govendor sync
Trash
trash
Once the agent has evaluated the open source libraries in use, it produces a summary of the scan results that includes counts for total libraries used, vulnerable libraries, percentage of third party code, and a list of the vulnerabilities found:
Configuring Scans
By adding a srcclr.yml file to the directory where you point the Veracode SCA agent, you can specify scan directives which can be used for scanning your Go code. The following are configuration options which can be used within your srcclr.yml for Go scanning:
Directive | Description | Build/Package Managers |
---|---|---|
FORCE_GO_INSTALL | Specifies whether the Go dependencies will need to be installed | Go Get, Go modules, Govendor, Geodep, Trash, Glide |
Viewing Scan Results
After completing a scan, the bottom of the output in your terminal will include a link to the Veracode Platform to view the scan results in more detail:
Licenses Unique Library Licenses 4 Libraries Using GPL 0 Libraries With No License 2 Full Report Details https://acmedemo.sourceclear.io/teams/X33hObV/scans/2075043
Navigating to this link will allow you to view the results of your scan in its entirety.
The scan results are broken down into the following categories:
- Issues: This is comprised of out of date libraries, license violations, and vulnerabilities uniquely associated to a specific version of a library within a specific repository.
- Vulnerabilities: This list represents the set of unique vulnerabilities across a specific project. If multiple libraries in a given project are associated with the same vulnerability, the vulnerability will only appear once in this list.
- Libraries: Libraries consist of each open source library that Veracode SCA has identified within a code project.
- Licenses: Licenses allow users to view the software license information associated with each open source library in use.
You can find more details on these categories in the Issues, Vulnerabilities, Libraries, and Licensesdocumentation article.
Fixing Vulnerability Issues
After viewing the scan results, users will likely want to fix the vulnerabilities discovered in their Go project. Veracode SCA provides clear instructions for fixing vulnerability issues through the web interface.
Fixing a Direct Vulnerability
When your configuration file specifically references a library, Veracode SCA refers to the library as a direct dependency. Fixing a vulnerability in a direct dependency using agent-based scanning is simple. After navigating to the project scan results within the Veracode Platform, you can filter down to Vulnerability issues, which are included only in Direct Libraries:
After filtering the scan results, you can drill into an issue to find out how to fix it by clicking the issue id next to the vulnerability name. This will bring you to the issue details page, where you will find information on fixing the vulnerability. In general, the best way to fix a vulnerability in a direct dependency is to update the version in use to the version recommended by Veracode SCA. The agent-based scan recommends a version which is not associated with the vulnerability you are subject to, in addition to any other vulnerabilities which might result from switching to a different version. In order to prevent the update from having significant impact on your code, the recommended version will be the closest to your current version while still not being associated with other vulnerabilities.
Validating a Fixed Vulnerability
Prior to committing your code changes, run an agent-based scan to validate the fix you made to your repository by adding the --allow-dirty option to ignore uncommitted changes within your code:
srcclr scan /path/to/example-go-glide --allow-dirty
After you have verified the finding no longer shows up in the scan output, you can proceed to commit your code to fix the finding.