Go packaging

Your Go applications must meet specific compilation requirements before you can submit them for scanning.

See Supported languages and platforms for instructions for other platforms.

You can analyze applications using Veracode Static Analysis or Veracode Software Composition Analysis (SCA) upload and scan, if licensed. For SCA agent-based scan requirements, see Using Veracode SCA with Programming Languages.

Automated packaging

Auto-packaging simplifies the packaging process for Go projects.

Supported Go versions

Language	Version
Go	1.22 and earlier

Supported Go frameworks and libraries

Framework/Library	Notes
Gorilla	Includes support for mux, handlers, HTTP, session, and additional Gorilla components
Gin Web Framework (Gin-Gonic)	1.7.x
AWS SDK for Go	v2

Packaging guidance for Go

Veracode uses functionality in the standard Go compiler when analyzing applications, and requires that the application is packaged in a structure that can be compiled. Package the source directory for a single compilable Go executable as a compressed ZIP archive, and structure it using these rules:

• The ZIP archive must contain a single directory.

• Veracode Static Analysis does not download any third-party libraries, but does require that all libraries are in a vendor directory that you created using the vendoring functionality in Go. To create the vendor directory during application builds with Go 1.11 or later, you can use the -mod=vendor option, or run the go mod vendor command.

  • You must place any third-party libraries or other internal packages in a subdirectory named vendor. For example: vendor/github.com/my_org/my_application
  • Any dependencies that the application uses must be in the vendor subdirectory.
  • To avoid scan errors, do not use the replace function in your go.mod file. For example, if your go.mod file contains the following replace functions, you must remove them.

    replace github.com/pselle/bar => /Users/pselle/Projects/bar
    or

    replace github.com/pselle/bar => ./bar

  To remove the functions, run go mod vendor and ensure that you only have vendor/github.com/pselle/bar.

  For more information, see How do I use vendoring with modules?

  If the top-level directory contains a go.mod file, Veracode Static Analysis uses the module directive to detect the module path. For example, the mymod folder in your application might include a go.mod file that contains module github.com/user/mymod. You can import github.com/user/mymod/stringutil even if you archive only the mymod folder, instead of the entire path github.com/user/mymod.

  For more information, see the go.mod Wiki page.

• The application must not include any cgo dependencies or build tags that restrict the application to running only on a specific operating system or with specific options.

• Any packages that the application uses that are specific to the application must be contained in a subdirectory inside the app directory.

This example shows the structure of the submitted source files:

app.zip
|__ app/
    |-- [go.mod if used]
    |-- [any *.go files in the root package]
    |__ applicationpkg1/
        |-- [application package 1 *.go files]
    |__ applicationpkg2/
        |-- [application package 2 *.go files]
    |__ vendor/ [first- and third-party dependencies go in this folder]

Upload requirements

• An upload must only contain one Go module.
• You must split a multi-module project into separate uploads.
• The go.mod file for a module must be in the top-level directory of your archive.

Veracode does not support uploading a source repository that includes the source for multiple discrete Go executables or multiple modules.

Configuration of scope

If the application you want to analyze contains first-party code that you want to analyze in the vendor directory, you can specify this in a configuration file.

In the root of the directory that you included in the ZIP archive, add a JSON file named veracode.json, with the optional FirstParty property. The FirstParty property describes an array of import paths for first-party code that is located in the vendor directory.

The following example shows the veracode.json configuration file:

{
    "FirstParty": [
        "github.com/my_company"
    ]
}

The following example shows the application structure that uses the configuration file in the previous example:

app.zip
|__ app/
    |-- veracode.json [configuration file, see above]
    |__ cmd/
        |__ app1
            |-- main.go
    |__ vendor/ [first- and third-party dependencies go in this folder]
        |__ golang.org/
        |__ gopkg.in/
        |__ github.com/ 
            |__ my_company/ [marked as 'first-party' and included in analysis]
                |__ firstpartypkg1/
                |__ firstpartypkg2/
            |__ 3rdparty [marked as 'third-party' and not included in analysis]

Details and troubleshooting

To analyze the applications, Veracode Static Analysis first uses the Go compiler to generate syntax trees. It then unzips the uploaded archive of your application to an empty workspace directory. The $GOPATH environment variable is set to this workspace. Veracode scans each directory in this workspace for Go files and analyzes each function.

You can validate that the application compiles by running the go build command after unzipping the file into a blank directory, or by running the go vet command on it to identify any issues with the structure of the directory and package layout. If the application is unable to compile after being unzipped into a blank directory, Veracode cannot analyze the application.

To better understand the use of the vendor folder, review the Go documentation.

If your application includes vendor dependencies that contain code in languages other than Go, you should remove them with this command:

find /<path>/app/vendor -type f -not -name '*.go' -delete

Veracode scans only GO files that have the GO extension.

When creating an archive of a Go application on macOS, the folder compression process creates hidden __MACOSX resource fork files that you must remove. To remove the hidden resource fork files:

1. Run zipinfo my.zip on the Go application archive to view a list of its files.
2. Review the list of files to verify that all resource fork files are removed.
3. Remove resource fork files from an existing archive on macOS using this command: zip -d my.zip "__MACOSX/*"

Package manager requirements for Software Composition Analysis

Ensure your package managers meet the following requirements:

Dep

Include gopkg.lock in the root of your ZIP archive.

Glide

Include glide.lock in the root of your ZIP archive.

Go Modules

• Include the go.sum file in the top-level directory of your archive.
• To have SCA use the content in the vendor directory to exclude non-vendored dependencies from scan results, Veracode recommends Go version 1.14 or later.
• To create the vendor directory, use the -mod=vendor option or run the command: go mod vendor. For more information, see the Go documentation.

Godep

Include godeps/godeps.lock in the root of your ZIP archive.

Govendor

Include vendor/vendor.json in the root of your ZIP archive.