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

Autopackaging simplifies the packaging process for Go projects.

Supported Go versions

Language	Version
Go	1.26 and earlier

Supported Go frameworks and libraries

Framework/Library	Notes
Cobra	1.8.x
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
Fiber Web Framework	v2.x
FastHTTP	v1.62.x

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.

• To package an application that includes CGO dependencies or build tags that restrict the application to a specific operating system or configuration, use the veracode package command with the environment variable VERACODE_PACKAGE_GOLANG_GENERATE set to on.

• 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 an application, Veracode Static Analysis unzips the uploaded archive into an empty temporary directory and sets the $GOPATH environment variable to that directory. Static Analysis then uses the Go compiler to generate syntax trees, scans each directory in the temporary directory for Go source files, and analyzes each function.

To verify that your application compiles, unzip the archive into an empty directory and run the go build command. You can also run the go vet command to identify potential problems with the directory structure and package layout. If the application does not compile after you unzip it into an empty directory, Veracode cannot analyze it.

For more information about using the vendor directory, see the Go documentation.

Many packaging issues can be resolved by using autopackaging, which automates packaging your application for Static Analysis.

If you package your application manually and have verified that it does not require vendor dependency files other than Go source files or Go module metadata, you can remove the other files with this command:

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

After running the command, verify again that your application compiles.

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

1. Run zipinfo my.zip on the Go application archive to view a list of its files.
2. Review the list for __MACOSX resource fork files.
3. If the archive contains these files, remove them by running zip -d my.zip "__MACOSX/*".
4. Run zipinfo my.zip again to verify that the files were removed.

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.